From greg.ewing at canterbury.ac.nz  Sun Aug  1 02:41:02 2010
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sun, 01 Aug 2010 12:41:02 +1200
Subject: [Python-Dev] Is it intentional that "sys.__debug__ = 1" is
 illegal in Python 2.7?
In-Reply-To: <20100731123625.3eeb018f@heresy>
References: <20100730162608.7315c3a5@heresy> <20100730165325.49414a21@heresy>
	<AANLkTim=Joj=+4a29vNTQtWdheAmA76089njCAu+U6J1@mail.gmail.com>
	<201007310833.00914.steve@pearwood.info>
	<20100731123625.3eeb018f@heresy>
Message-ID: <4C54C29E.4000008@canterbury.ac.nz>

Barry Warsaw wrote:
> I've always understood the rules on
> double-underscore names to mean that Python reserves the use of those names
> for its own purposes, and is free to break your code if you define your own.
> That's very different than saying it's forbidden to use double-underscore
> names for your own purposes or assign to them, which is I think what's going
> on with the sys.__debug__ example.

I don't see that there's any difference. Once upon a time,
__debug__ wasn't special, and someone decided to use it for
their own purposes. Then Guido decided to make it special,
and broke their code, which is within the rules as you
just stated them. The rule doesn't say anything about what
*kinds* of breakage are allowed, so anything goes, including
making it impossible to assign to the name any more.

-- 
Greg

From breamoreboy at yahoo.co.uk  Sun Aug  1 02:48:47 2010
From: breamoreboy at yahoo.co.uk (Mark Lawrence)
Date: Sun, 01 Aug 2010 01:48:47 +0100
Subject: [Python-Dev] No response to posts
Message-ID: <i32g9g$ouf$1@dough.gmane.org>

Hi all,

I have been wading through outstanding issues today and have noticed 
that there are several where there has been no response at all to the 
initial post.  Failing that, the only response has been Terry Reedy back 
in May 2010, and that only updating the versions affected.

Would it be possible to get some code in place whereby if there is no 
response to the initial post, this could be flagged up after (say) 24 
hours?  Surely any response back to the OP is better than a complete 
wall of silence?

Kindest regards.

Mark Lawrence.


From greg.ewing at canterbury.ac.nz  Sun Aug  1 03:01:32 2010
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sun, 01 Aug 2010 13:01:32 +1200
Subject: [Python-Dev] Exception chaining and generator finalisation
Message-ID: <4C54C76C.7070008@canterbury.ac.nz>

While updating my yield-from impementation for Python
3.1.2, I came across a quirk in the way that the new
exception chaining feature interacts with generators.

If you close() a generator, and it raises an exception
inside a finally clause, you get a double-barrelled
traceback that first reports a GeneratorExit, then
"During handling of the above exception, another
exception occurred", followed by the traceback for
the exception raised by the generator.

To my mind, the fact that GeneratorExit is involved
is an implementation detail that shouldn't be leaking
through like this.

Does anyone think this ought to be fixed, and if so,
how? Should GeneratorExit be exempt from being
implicitly set as the context of another exception?
Should any other exceptions also be exempt?

Demonstration follows:

Python 3.1.2 (r312:79147, Jul 31 2010, 21:23:14)
[GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
 >>> def g():
...  try:
...   yield 1
...  finally:
...   raise ValueError("Spanish inquisition")
...
 >>> gi = g()
 >>> next(gi)
1
 >>> gi.close()
Traceback (most recent call last):
   File "<stdin>", line 3, in g
GeneratorExit

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
   File "<stdin>", line 5, in g
ValueError: Spanish inquisition

-- 
Greg

From winston at netwok.org  Sun Aug  1 02:53:56 2010
From: winston at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Sun, 01 Aug 2010 02:53:56 +0200
Subject: [Python-Dev] No response to posts
In-Reply-To: <i32g9g$ouf$1@dough.gmane.org>
References: <i32g9g$ouf$1@dough.gmane.org>
Message-ID: <4C54C5A4.6080409@netwok.org>

Good call.

Alternative idea: Have a new status ?unread? to make searching easier
for bug people. Or a predefined custom search for nosy_count == 1.

Regards


From brian.curtin at gmail.com  Sun Aug  1 03:00:57 2010
From: brian.curtin at gmail.com (Brian Curtin)
Date: Sat, 31 Jul 2010 20:00:57 -0500
Subject: [Python-Dev] No response to posts
In-Reply-To: <i32g9g$ouf$1@dough.gmane.org>
References: <i32g9g$ouf$1@dough.gmane.org>
Message-ID: <AANLkTi=5xfXtYbRbe8ZD5XmG7vApWZhbnm-vk3qq13Xg@mail.gmail.com>

On Sat, Jul 31, 2010 at 19:48, Mark Lawrence <breamoreboy at yahoo.co.uk>wrote:

> Hi all,
>
> I have been wading through outstanding issues today and have noticed that
> there are several where there has been no response at all to the initial
> post.  Failing that, the only response has been Terry Reedy back in May
> 2010, and that only updating the versions affected.
>
> Would it be possible to get some code in place whereby if there is no
> response to the initial post, this could be flagged up after (say) 24 hours?
>  Surely any response back to the OP is better than a complete wall of
> silence?
>
> Kindest regards.
>
> Mark Lawrence.
>

We could just add globally visible query which shows all issues with a
message count of 1. That query currently shows 372 issues, most of which
were entered within the last few months.

24 hours seems too soon for any kind of notification. Who would receive this
notification?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100731/7ba30705/attachment.html>

From ncoghlan at gmail.com  Sun Aug  1 03:21:54 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 1 Aug 2010 11:21:54 +1000
Subject: [Python-Dev] Exception chaining and generator finalisation
In-Reply-To: <4C54C76C.7070008@canterbury.ac.nz>
References: <4C54C76C.7070008@canterbury.ac.nz>
Message-ID: <AANLkTimL+cE4b09m-btOJEO4RiEmW0LMAsEu=1ZTQgi3@mail.gmail.com>

On Sun, Aug 1, 2010 at 11:01 AM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> While updating my yield-from impementation for Python
> 3.1.2, I came across a quirk in the way that the new
> exception chaining feature interacts with generators.
>
> If you close() a generator, and it raises an exception
> inside a finally clause, you get a double-barrelled
> traceback that first reports a GeneratorExit, then
> "During handling of the above exception, another
> exception occurred", followed by the traceback for
> the exception raised by the generator.
>
> To my mind, the fact that GeneratorExit is involved
> is an implementation detail that shouldn't be leaking
> through like this.
>
> Does anyone think this ought to be fixed, and if so,
> how? Should GeneratorExit be exempt from being
> implicitly set as the context of another exception?
> Should any other exceptions also be exempt?

I don't see it as an implementation detail - it's part of the spec of
generator finalisation in PEP 342 that GeneratorExit is thrown in to
the incomplete generator at the point of the most recent yield. Trying
to hide that doesn't benefit anybody.

SystemExit and KeyboardInterrupt behave the same way:

Python 3.2a0 (py3k:82729, Jul  9 2010, 20:26:08)
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> try:
...   sys.exit(1)
... finally:
...   raise RuntimeError("Ooops")
...
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
SystemExit: 1

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 4, in <module>
RuntimeError: Ooops

>>> try:
...   input("Hit Ctrl-C now")
... finally:
...   raise RuntimeError("Ooops")
...
Hit Ctrl-C nowTraceback (most recent call last):
  File "<stdin>", line 2, in <module>
KeyboardInterrupt

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 4, in <module>
RuntimeError: Ooops


Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From ncoghlan at gmail.com  Sun Aug  1 03:23:18 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 1 Aug 2010 11:23:18 +1000
Subject: [Python-Dev] No response to posts
In-Reply-To: <AANLkTi=5xfXtYbRbe8ZD5XmG7vApWZhbnm-vk3qq13Xg@mail.gmail.com>
References: <i32g9g$ouf$1@dough.gmane.org>
	<AANLkTi=5xfXtYbRbe8ZD5XmG7vApWZhbnm-vk3qq13Xg@mail.gmail.com>
Message-ID: <AANLkTinQvZ7JCQe=aFR=pAhP3HzjH9dm6PPOMzo6tX9O@mail.gmail.com>

On Sun, Aug 1, 2010 at 11:00 AM, Brian Curtin <brian.curtin at gmail.com> wrote:
> We could just add globally visible query which shows all issues with a
> message count of 1. That query currently shows 372 issues, most of which
> were entered within the last few months.
> 24 hours seems too soon for any kind of notification. Who would receive this
> notification?

The query for unreviewed issues to help out the triage folks sounds
like an excellent idea.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From greg.ewing at canterbury.ac.nz  Sun Aug  1 05:25:43 2010
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sun, 01 Aug 2010 15:25:43 +1200
Subject: [Python-Dev] Exception chaining and generator finalisation
In-Reply-To: <AANLkTimL+cE4b09m-btOJEO4RiEmW0LMAsEu=1ZTQgi3@mail.gmail.com>
References: <4C54C76C.7070008@canterbury.ac.nz>
	<AANLkTimL+cE4b09m-btOJEO4RiEmW0LMAsEu=1ZTQgi3@mail.gmail.com>
Message-ID: <4C54E937.7020305@canterbury.ac.nz>

Nick Coghlan wrote:

> I don't see it as an implementation detail - it's part of the spec of
> generator finalisation in PEP 342

It doesn't seem like something you need to know in this
situation, though. All it tells you is that the finalisation
is happening because the generator is being closed rather
than completing on its own.

I suppose it doesn't do any harm, but it seems untidy to
clutter up the traceback with irrelevant and possibly
confusing information.

> Hit Ctrl-C nowTraceback (most recent call last):
>   File "<stdin>", line 2, in <module>
> KeyboardInterrupt
> 
> During handling of the above exception, another exception occurred:
> 
> Traceback (most recent call last):
>   File "<stdin>", line 4, in <module>
> RuntimeError: Ooops

That's a bit different, because the fact that the program
was terminated by Ctrl-C could be useful information.

-- 
Greg

From solipsis at pitrou.net  Sun Aug  1 05:46:46 2010
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sun, 1 Aug 2010 05:46:46 +0200
Subject: [Python-Dev] Exception chaining and generator finalisation
References: <4C54C76C.7070008@canterbury.ac.nz>
Message-ID: <20100801054646.1abab7b1@pitrou.net>

On Sun, 01 Aug 2010 13:01:32 +1200
Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> While updating my yield-from impementation for Python
> 3.1.2, I came across a quirk in the way that the new
> exception chaining feature interacts with generators.
> 
> If you close() a generator, and it raises an exception
> inside a finally clause, you get a double-barrelled
> traceback that first reports a GeneratorExit, then
> "During handling of the above exception, another
> exception occurred", followed by the traceback for
> the exception raised by the generator.

It only happens if you call close() explicitly:

>>> def g():
...   try: yield 1
...   finally: 1/0
... 
>>> gi = g()
>>> next(gi)
1
>>> del gi
Exception ZeroDivisionError: ZeroDivisionError('division by zero',) in
<generator object g at 0x7fe50351ddc0> ignored
>>> gi = g()
>>> next(gi)
1
>>> next(gi)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 3, in g
ZeroDivisionError: division by zero
>>> 


Regards

Antoine.



From ncoghlan at gmail.com  Sun Aug  1 07:51:09 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 1 Aug 2010 15:51:09 +1000
Subject: [Python-Dev] Exception chaining and generator finalisation
In-Reply-To: <4C54E937.7020305@canterbury.ac.nz>
References: <4C54C76C.7070008@canterbury.ac.nz>
	<AANLkTimL+cE4b09m-btOJEO4RiEmW0LMAsEu=1ZTQgi3@mail.gmail.com>
	<4C54E937.7020305@canterbury.ac.nz>
Message-ID: <AANLkTikfP7B-EH2UdvgNC75NM9ag7_2cZk6ys+BOkDY8@mail.gmail.com>

On Sun, Aug 1, 2010 at 1:25 PM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Nick Coghlan wrote:
>
>> I don't see it as an implementation detail - it's part of the spec of
>> generator finalisation in PEP 342
>
> It doesn't seem like something you need to know in this
> situation, though. All it tells you is that the finalisation
> is happening because the generator is being closed rather
> than completing on its own.

That may be important though (e.g. if the generator hasn't been
written to correctly take into account the possibility of exceptions
being thrown in, then knowing the exception happened when
GeneratorExit in particular was thrown in rather than when next() was
called or a different exception was thrown in may matter for the
debugging process).

Basically, I disagree with your assumption that knowing GeneratorExit
was involved won't be significant in figuring why the generator threw
an exception at all, so I see this as providing useful exception
context information rather than being untidy noise. A toy example,
that isn't obviously broken at first glance, but in fact fails when
close() is called:

def toy_gen():
    try:
       yield 1
    except Exception as ex:
      exc = ex
    else:
      exc = None
    finally:
      if exc is not None: print(type(exc))

>>> g = toy_gen()
>>> next(g)
1
>>> g.throw(NameError)
<class 'NameError'>
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
StopIteration
>>> g = toy_gen()
>>> next(g)
1
>>> g.close()
Traceback (most recent call last):
  File "<stdin>", line 3, in toy_gen
GeneratorExit

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 9, in toy_gen
UnboundLocalError: local variable 'exc' referenced before assignment

Without knowing GeneratorExit was thrown, the UnboundLocalError would
be rather confusing. Given GeneratorExit to work with though, it
shouldn't be hard for a developer to realise that "exc" won't be set
when a thrown exception inherits directly from BaseException rather
than from Exception.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From greg.ewing at canterbury.ac.nz  Sun Aug  1 09:45:31 2010
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sun, 01 Aug 2010 19:45:31 +1200
Subject: [Python-Dev] Exception chaining and generator finalisation
In-Reply-To: <20100801054646.1abab7b1@pitrou.net>
References: <4C54C76C.7070008@canterbury.ac.nz>
	<20100801054646.1abab7b1@pitrou.net>
Message-ID: <4C55261B.7020007@canterbury.ac.nz>

Antoine Pitrou wrote:

> It only happens if you call close() explicitly:

Well, that's only because the exception is being ignored and
you're not getting a traceback at all.

If you arrange to get a traceback, the same thing happens.

   import traceback as tb

   def g():
     try:
       try:
         yield 1
       finally:
         raise ValueError("Hovercraft contains eels")
     except Exception:
       tb.print_exc()

   gi = g()
   next(gi)
   del gi

-- 
Greg


> 
>>>>def g():
> 
> ...   try: yield 1
> ...   finally: 1/0
> ... 
> 
>>>>gi = g()
>>>>next(gi)
> 
> 1
> 
>>>>del gi
> 
> Exception ZeroDivisionError: ZeroDivisionError('division by zero',) in
> <generator object g at 0x7fe50351ddc0> ignored
> 
>>>>gi = g()
>>>>next(gi)
> 
> 1
> 
>>>>next(gi)
> 
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
>   File "<stdin>", line 3, in g
> ZeroDivisionError: division by zero
> 
> 
> 
> Regards
> 
> Antoine.
> 
> 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/greg.ewing%40canterbury.ac.nz


From greg.ewing at canterbury.ac.nz  Sun Aug  1 09:50:10 2010
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sun, 01 Aug 2010 19:50:10 +1200
Subject: [Python-Dev] Exception chaining and generator finalisation
In-Reply-To: <AANLkTikfP7B-EH2UdvgNC75NM9ag7_2cZk6ys+BOkDY8@mail.gmail.com>
References: <4C54C76C.7070008@canterbury.ac.nz>
	<AANLkTimL+cE4b09m-btOJEO4RiEmW0LMAsEu=1ZTQgi3@mail.gmail.com>
	<4C54E937.7020305@canterbury.ac.nz>
	<AANLkTikfP7B-EH2UdvgNC75NM9ag7_2cZk6ys+BOkDY8@mail.gmail.com>
Message-ID: <4C552732.9030907@canterbury.ac.nz>

Nick Coghlan wrote:
> A toy example,
> that isn't obviously broken at first glance, but in fact fails when
> close() is called:

Okay, you've convinced me. I'll consider it to be correct
behaviour and update my expected yield-from test results
accordingly.

-- 
Greg


From breamoreboy at yahoo.co.uk  Sun Aug  1 09:41:56 2010
From: breamoreboy at yahoo.co.uk (Mark Lawrence)
Date: Sun, 01 Aug 2010 08:41:56 +0100
Subject: [Python-Dev] No response to posts
In-Reply-To: <AANLkTi=5xfXtYbRbe8ZD5XmG7vApWZhbnm-vk3qq13Xg@mail.gmail.com>
References: <i32g9g$ouf$1@dough.gmane.org>
	<AANLkTi=5xfXtYbRbe8ZD5XmG7vApWZhbnm-vk3qq13Xg@mail.gmail.com>
Message-ID: <i338g6$9o7$1@dough.gmane.org>

On 01/08/2010 02:00, Brian Curtin wrote:
> On Sat, Jul 31, 2010 at 19:48, Mark Lawrence<breamoreboy at yahoo.co.uk>wrote:
>
>> Hi all,
>>
>> I have been wading through outstanding issues today and have noticed that
>> there are several where there has been no response at all to the initial
>> post.  Failing that, the only response has been Terry Reedy back in May
>> 2010, and that only updating the versions affected.
>>
>> Would it be possible to get some code in place whereby if there is no
>> response to the initial post, this could be flagged up after (say) 24 hours?
>>   Surely any response back to the OP is better than a complete wall of
>> silence?
>>
>> Kindest regards.
>>
>> Mark Lawrence.
>>
>
> We could just add globally visible query which shows all issues with a
> message count of 1. That query currently shows 372 issues, most of which
> were entered within the last few months.

The query strikes me as KISS, let's try it and see how we go.  On this 
thread on c.l.py "500 tracker orphans; we need more reviewers" started 
by Terry Reedy it was quoted that there were 510 orphans as at Jun 19, 
3:37 am.  We're getting there.

>
> 24 hours seems too soon for any kind of notification. Who would receive this
> notification?

I plucked this figure out of the air thinking that if an issue was going 
to drop under the radar, this would be the most likely time.  I was 
considering a worst case scenario where several core triage people are 
at a big Python event, others are on holiday [ shame on you :) ], some 
looking after the kids, yet more off sick etc.  Hum, perhaps 24 hours is 
too soon, what about a week, opinions anybody?  Notifications would go 
to the bugs mailing list and/or #python-dev.  But this is hypothetical 
anyway if the message count of 1 query works.  Only one way to find out, 
let's try it.

Kindest regards.

Mark Lawrence.



From greg.ewing at canterbury.ac.nz  Sun Aug  1 09:54:56 2010
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sun, 01 Aug 2010 19:54:56 +1200
Subject: [Python-Dev] Yield-From Implementation Updated for Python 3
Message-ID: <4C552850.8020406@canterbury.ac.nz>

I have updated my prototype yield-from implementation
to work with Python 3.1.2.

I've also fixed a small bug that was affecting one of
the corner cases concerning exceptions thrown into
a subgenerator.

Interested parties can obtain it here:

http://www.cosc.canterbury.ac.nz/greg.ewing/python/yield-from/

-- 
Greg

From georg at python.org  Sun Aug  1 11:38:35 2010
From: georg at python.org (Georg Brandl)
Date: Sun, 01 Aug 2010 11:38:35 +0200
Subject: [Python-Dev] [RELEASED] Python 3.2 alpha 1
Message-ID: <4C55409B.5000409@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On behalf of the Python development team, I'm happy to announce the
first alpha preview release of Python 3.2.

Python 3.2 is a continuation of the efforts to improve and stabilize the
Python 3.x line.  Since the final release of Python 2.7, the 2.x line
will only receive bugfixes, and new features are developed for 3.x only.

Since PEP 3003, the Moratorium on Language Changes, is in effect, there
are no changes in Python's syntax and built-in types in Python 3.2.
Development efforts concentrated on the standard library and support for
porting code to Python 3.  Highlights are:

* numerous improvements to the unittest module
* PEP 3147, support for .pyc repository directories
* an overhauled GIL implementation that reduces contention
* many consistency and behavior fixes for numeric operations
* countless fixes regarding string/unicode issues; among them full
  support for a bytes environment (filenames, environment variables)
* a sysconfig module to access configuration information
* a pure-Python implementation of the datetime module
* additions to the shutil module, among them archive file support
* improvements to pdb, the Python debugger

For an extensive list of changes in 3.2, see Misc/NEWS in the Python
distribution.

To download Python 3.2 visit:

     http://www.python.org/download/releases/3.2/

3.2 documentation can be found at:

     http://docs.python.org/3.2/

Please consider trying Python 3.2 with your code and reporting any bugs
you may notice to:

     http://bugs.python.org/


Enjoy!

- --
Georg Brandl, Release Manager
georg at python.org
(on behalf of the entire python-dev team and 3.2's contributors)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)

iEYEARECAAYFAkxVQJsACgkQN9GcIYhpnLBxIgCcCiVu/QUkFf0bYM2Vmi8St3mZ
2N4An04q36lr47OA+bslqG/4Zj7ZwVOX
=iL8N
-----END PGP SIGNATURE-----

From ncoghlan at gmail.com  Sun Aug  1 13:28:05 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 1 Aug 2010 21:28:05 +1000
Subject: [Python-Dev] No response to posts
In-Reply-To: <i338g6$9o7$1@dough.gmane.org>
References: <i32g9g$ouf$1@dough.gmane.org>
	<AANLkTi=5xfXtYbRbe8ZD5XmG7vApWZhbnm-vk3qq13Xg@mail.gmail.com>
	<i338g6$9o7$1@dough.gmane.org>
Message-ID: <AANLkTin7oUUcOZFqBQnRe+0PFSPj78bEtD9p179YMe4Z@mail.gmail.com>

On Sun, Aug 1, 2010 at 5:41 PM, Mark Lawrence <breamoreboy at yahoo.co.uk> wrote:
> I plucked this figure out of the air thinking that if an issue was going to
> drop under the radar, this would be the most likely time. ?I was considering
> a worst case scenario where several core triage people are at a big Python
> event, others are on holiday [ shame on you :) ], some looking after the
> kids, yet more off sick etc. ?Hum, perhaps 24 hours is too soon, what about
> a week, opinions anybody? ?Notifications would go to the bugs mailing list
> and/or #python-dev. ?But this is hypothetical anyway if the message count of
> 1 query works. ?Only one way to find out, let's try it.

Perhaps just another number to track in the weekly bug summary?

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From merwok at netwok.org  Sun Aug  1 13:44:36 2010
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Sun, 01 Aug 2010 13:44:36 +0200
Subject: [Python-Dev] No response to posts
In-Reply-To: <AANLkTin7oUUcOZFqBQnRe+0PFSPj78bEtD9p179YMe4Z@mail.gmail.com>
References: <i32g9g$ouf$1@dough.gmane.org>	<AANLkTi=5xfXtYbRbe8ZD5XmG7vApWZhbnm-vk3qq13Xg@mail.gmail.com>	<i338g6$9o7$1@dough.gmane.org>
	<AANLkTin7oUUcOZFqBQnRe+0PFSPj78bEtD9p179YMe4Z@mail.gmail.com>
Message-ID: <4C555E24.9040007@netwok.org>

> Perhaps just another number to track in the weekly bug summary?

*puts bug person hat on* I made the same suggestion to Ezio, so +1

I?ve just created a public query named ?Reports without replies?, you
should be able to add it to your queries list, or a tracker admin could
decide to add it to the queries that are always visible in the sidebar.

Regards


From bioinformed at gmail.com  Sun Aug  1 14:49:17 2010
From: bioinformed at gmail.com (Kevin Jacobs <jacobs@bioinformed.com>)
Date: Sun, 1 Aug 2010 08:49:17 -0400
Subject: [Python-Dev] Yield-From Implementation Updated for Python 3
In-Reply-To: <4C552850.8020406@canterbury.ac.nz>
References: <4C552850.8020406@canterbury.ac.nz>
Message-ID: <AANLkTin0S5R9qAMoo4i3-E1=d1ZJ8-5=DScsee1Ljtcr@mail.gmail.com>

On Sun, Aug 1, 2010 at 3:54 AM, Greg Ewing <greg.ewing at canterbury.ac.nz>wrote:

> I have updated my prototype yield-from implementation
> to work with Python 3.1.2.
>
>
My work is primarily on the management and analysis of huge genomics
datasets.  I use Python generators extensively and intensively to perform
efficient computations and transformations on these datasets that avoid the
need to materialize them in main memory to the extent possible.   I've spent
a great deal of effort working around the lack of an efficient "yield from"
construct and would be very excited to see this feature added.  More so, now
that BioPython, NumPy, SciPy and other libraries that I depend on are well
on their way to supporting Python 3, the availability of this feature alone
would be incentive enough to update my code base to Python 3.

So in short:

+1

-Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100801/f0fdf789/attachment.html>

From ronaldoussoren at mac.com  Sun Aug  1 14:55:23 2010
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Sun, 01 Aug 2010 14:55:23 +0200
Subject: [Python-Dev] proto-pep: plugin proposal (for unittest)
In-Reply-To: <4C540F95.9030606@voidspace.org.uk>
References: <4C5206F6.7090808@voidspace.org.uk>
	<AANLkTi=rgKJMRQ_shwAbJ3S-fKpsoxGkvUFpi2mXc-2X@mail.gmail.com>
	<AANLkTimJ7XeVMFUv_Mi1gZoayBzc23EO8snk-CbWKZ8q@mail.gmail.com>
	<4C540CFD.9030308@voidspace.org.uk> <4C540F95.9030606@voidspace.org.uk>
Message-ID: <2E05BE10-4098-4133-AD6D-F26598519E3E@mac.com>


On 31 Jul, 2010, at 13:57, Michael Foord wrote:

> On 31/07/2010 12:46, Michael Foord wrote:
>> [snip...]
>> If PEP 376 goes ahead then we could keep the user plugin 
> 
> I meant "keep the user config file".

Speaking of which... Your documentation says it's named ~/unittest.cfg, could you make this a file in the user base (that is, the prefix where 'setup.py install --user' will install files)?

Ronald
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3567 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100801/f1a071d6/attachment.bin>

From merwok at netwok.org  Sun Aug  1 17:22:55 2010
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Sun, 01 Aug 2010 17:22:55 +0200
Subject: [Python-Dev] proto-pep: plugin proposal (for unittest)
In-Reply-To: <2E05BE10-4098-4133-AD6D-F26598519E3E@mac.com>
References: <4C5206F6.7090808@voidspace.org.uk>	<AANLkTi=rgKJMRQ_shwAbJ3S-fKpsoxGkvUFpi2mXc-2X@mail.gmail.com>	<AANLkTimJ7XeVMFUv_Mi1gZoayBzc23EO8snk-CbWKZ8q@mail.gmail.com>	<4C540CFD.9030308@voidspace.org.uk>
	<4C540F95.9030606@voidspace.org.uk>
	<2E05BE10-4098-4133-AD6D-F26598519E3E@mac.com>
Message-ID: <4C55914F.60705@netwok.org>

> Speaking of which... Your documentation says it's named ~/unittest.cfg,
> could you make this a file in the user base (that is, the prefix where
> 'setup.py install --user' will install files)?

Putting .pydistutils.cfg .pypirc .unittest2.cfg .idlerc and possibly
other in the user home directory (or %APPDATA% on win32 and
what-have-you on Mac) is unnecessary clutter. However, $PYTHONUSERBASE
is not the right directory for configuration files, as pointed in
http://bugs.python.org/issue7175

It would be nice to agree on a ~/.python (resp. %APPADATA%/Python) or
$XDG_CONFIG_HOME/python directory and put config files there.

Regards


From rdmurray at bitdance.com  Sun Aug  1 19:38:38 2010
From: rdmurray at bitdance.com (R. David Murray)
Date: Sun, 01 Aug 2010 13:38:38 -0400
Subject: [Python-Dev] proto-pep: plugin proposal (for unittest)
In-Reply-To: <4C55914F.60705@netwok.org>
References: <4C5206F6.7090808@voidspace.org.uk>
	<AANLkTi=rgKJMRQ_shwAbJ3S-fKpsoxGkvUFpi2mXc-2X@mail.gmail.com>
	<AANLkTimJ7XeVMFUv_Mi1gZoayBzc23EO8snk-CbWKZ8q@mail.gmail.com>
	<4C540CFD.9030308@voidspace.org.uk>
	<4C540F95.9030606@voidspace.org.uk>
	<2E05BE10-4098-4133-AD6D-F26598519E3E@mac.com>
	<4C55914F.60705@netwok.org>
Message-ID: <20100801173838.D1DEC1BC38C@kimball.webabinitio.net>

On Sun, 01 Aug 2010 17:22:55 +0200, <merwok at netwok.org> wrote:
> > Speaking of which... Your documentation says it's named ~/unittest.cfg,
> > could you make this a file in the user base (that is, the prefix where
> > 'setup.py install --user' will install files)?
> 
> Putting .pydistutils.cfg .pypirc .unittest2.cfg .idlerc and possibly
> other in the user home directory (or %APPDATA% on win32 and
> what-have-you on Mac) is unnecessary clutter. However, $PYTHONUSERBASE
> is not the right directory for configuration files, as pointed in
> http://bugs.python.org/issue7175
> 
> It would be nice to agree on a ~/.python (resp. %APPADATA%/Python) or
> $XDG_CONFIG_HOME/python directory and put config files there.

+1

Certainly ~/unittest.cfg is the wrong name for unix (it doesn't start
with a '.'), and certainly the location is OS specific. 

Anyone who cares about config file locations should read issue 7175.

--
R. David Murray                                      www.bitdance.com

From rdmurray at bitdance.com  Sun Aug  1 19:43:43 2010
From: rdmurray at bitdance.com (R. David Murray)
Date: Sun, 01 Aug 2010 13:43:43 -0400
Subject: [Python-Dev] No response to posts
In-Reply-To: <AANLkTin7oUUcOZFqBQnRe+0PFSPj78bEtD9p179YMe4Z@mail.gmail.com>
References: <i32g9g$ouf$1@dough.gmane.org>
	<AANLkTi=5xfXtYbRbe8ZD5XmG7vApWZhbnm-vk3qq13Xg@mail.gmail.com>
	<i338g6$9o7$1@dough.gmane.org>
	<AANLkTin7oUUcOZFqBQnRe+0PFSPj78bEtD9p179YMe4Z@mail.gmail.com>
Message-ID: <20100801174343.5612E200239@kimball.webabinitio.net>

On Sun, 01 Aug 2010 21:28:05 +1000, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On Sun, Aug 1, 2010 at 5:41 PM, Mark Lawrence <breamoreboy at yahoo.co.uk> wrote:
> > I plucked this figure out of the air thinking that if an issue was going to
> > drop under the radar, this would be the most likely time. I was considering
> > a worst case scenario where several core triage people are at a big Python
> > event, others are on holiday [ shame on you :) ], some looking after the
> > kids, yet more off sick etc. Hum, perhaps 24 hours is too soon, what a bout
> > a week, opinions anybody? Notifications would go to the bugs mailing list
> > and/or #python-dev. But this is hypothetical anyway if the message count of
> > 1 query works. Only one way to find out, let's try it.
> 
> Perhaps just another number to track in the weekly bug summary?

Better, a table section giving the bugids, titles, and URL.  Ezio just
finished reworking the summary script to be more easily modified, so I
bet he would find this easy to add at this point.

--David

From pje at telecommunity.com  Sun Aug  1 20:16:23 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Sun, 01 Aug 2010 14:16:23 -0400
Subject: [Python-Dev] Yield-From Implementation Updated for Python 3
In-Reply-To: <AANLkTin0S5R9qAMoo4i3-E1=d1ZJ8-5=DScsee1Ljtcr@mail.gmail.c
 om>
References: <4C552850.8020406@canterbury.ac.nz>
	<AANLkTin0S5R9qAMoo4i3-E1=d1ZJ8-5=DScsee1Ljtcr@mail.gmail.com>
Message-ID: <20100801181619.537B13A4175@sparrow.telecommunity.com>

At 08:49 AM 8/1/2010 -0400, Kevin Jacobs <jacobs at bioinformed.com> wrote:
>On Sun, Aug 1, 2010 at 3:54 AM, Greg Ewing 
><<mailto:greg.ewing at canterbury.ac.nz>greg.ewing at canterbury.ac.nz> wrote:
>I have updated my prototype yield-from implementation
>to work with Python 3.1.2.
>
>
>My work is primarily on the management and analysis of huge genomics 
>datasets.  I use Python generators extensively and intensively to 
>perform efficient computations and transformations on these datasets 
>that avoid the need to materialize them in main memory to the extent 
>possible.   I've spent a great deal of effort working around the 
>lack of an efficient "yield from" construct and would be very 
>excited to see this feature added.

Just so you know, you don't need to wait for this to be added to 
Python in order to have such a construct; it just won't have the 
extra syntax sugar.  See the sample code I posted here using a 
"@From.container" decorator, and a "yield From()" call:

   http://mail.python.org/pipermail/python-dev/2010-July/102320.html

This code effectively reduces your generator nesting depth to a 
constant, no matter how deeply you nest sub-generator 
invocations.  It's not as efficient as the equivalent C 
implementation, but if you're actually being affected by nesting 
overhead now, it will nonetheless provide you with some immediate 
relief, if you backport it to 2.x code.  (It's not very 3.x-ish as it 
sits, really.)


From fuzzyman at voidspace.org.uk  Sun Aug  1 20:50:46 2010
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Sun, 01 Aug 2010 19:50:46 +0100
Subject: [Python-Dev] proto-pep: plugin proposal (for unittest)
In-Reply-To: <20100801173838.D1DEC1BC38C@kimball.webabinitio.net>
References: <4C5206F6.7090808@voidspace.org.uk>	<AANLkTi=rgKJMRQ_shwAbJ3S-fKpsoxGkvUFpi2mXc-2X@mail.gmail.com>	<AANLkTimJ7XeVMFUv_Mi1gZoayBzc23EO8snk-CbWKZ8q@mail.gmail.com>	<4C540CFD.9030308@voidspace.org.uk>	<4C540F95.9030606@voidspace.org.uk>	<2E05BE10-4098-4133-AD6D-F26598519E3E@mac.com>	<4C55914F.60705@netwok.org>
	<20100801173838.D1DEC1BC38C@kimball.webabinitio.net>
Message-ID: <4C55C206.3020207@voidspace.org.uk>

On 01/08/2010 18:38, R. David Murray wrote:
> On Sun, 01 Aug 2010 17:22:55 +0200,<merwok at netwok.org>  wrote:
>    
>>> Speaking of which... Your documentation says it's named ~/unittest.cfg,
>>> could you make this a file in the user base (that is, the prefix where
>>> 'setup.py install --user' will install files)?
>>>        
>> Putting .pydistutils.cfg .pypirc .unittest2.cfg .idlerc and possibly
>> other in the user home directory (or %APPDATA% on win32 and
>> what-have-you on Mac) is unnecessary clutter. However, $PYTHONUSERBASE
>> is not the right directory for configuration files, as pointed in
>> http://bugs.python.org/issue7175
>>
>> It would be nice to agree on a ~/.python (resp. %APPADATA%/Python) or
>> $XDG_CONFIG_HOME/python directory and put config files there.
>>      
> +1
>
> Certainly ~/unittest.cfg is the wrong name for unix (it doesn't start
> with a '.'), and certainly the location is OS specific.
>
> Anyone who cares about config file locations should read issue 7175.
>    

I'm happy to choose a location / name based on consensus. There doesn't 
seem to be any consensus yet. As a (mainly ex) windows user I would hate 
to have user editable data in APPDATA as it is not a location the user 
ever expects to visit. The home directory, or a subdirectory thereof, 
for user editable app specific data is more usual and more friendly.

All the best,

Michael Foord

> --
> R. David Murray                                      www.bitdance.com
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at 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/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (?BOGUS AGREEMENTS?) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.



From ronaldoussoren at mac.com  Sun Aug  1 21:52:30 2010
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Sun, 01 Aug 2010 21:52:30 +0200
Subject: [Python-Dev] proto-pep: plugin proposal (for unittest)
In-Reply-To: <4C55914F.60705@netwok.org>
References: <4C5206F6.7090808@voidspace.org.uk>
	<AANLkTi=rgKJMRQ_shwAbJ3S-fKpsoxGkvUFpi2mXc-2X@mail.gmail.com>
	<AANLkTimJ7XeVMFUv_Mi1gZoayBzc23EO8snk-CbWKZ8q@mail.gmail.com>
	<4C540CFD.9030308@voidspace.org.uk> <4C540F95.9030606@voidspace.org.uk>
	<2E05BE10-4098-4133-AD6D-F26598519E3E@mac.com>
	<4C55914F.60705@netwok.org>
Message-ID: <F7612A95-8B56-4037-85F0-799980C9DF8A@mac.com>


On 1 Aug, 2010, at 17:22, ?ric Araujo wrote:

>> Speaking of which... Your documentation says it's named ~/unittest.cfg,
>> could you make this a file in the user base (that is, the prefix where
>> 'setup.py install --user' will install files)?
> 
> Putting .pydistutils.cfg .pypirc .unittest2.cfg .idlerc and possibly
> other in the user home directory (or %APPDATA% on win32 and
> what-have-you on Mac) is unnecessary clutter. However, $PYTHONUSERBASE
> is not the right directory for configuration files, as pointed in
> http://bugs.python.org/issue7175
> 
> It would be nice to agree on a ~/.python (resp. %APPADATA%/Python) or
> $XDG_CONFIG_HOME/python directory and put config files there.

~/Library/Python would be a good location on OSX, even if the 100% formally correct location would be ~/Preferences/Python (at least of framework builds, unix-style builds may want to follow the unix convention).

Ronald

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3567 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100801/6242f625/attachment.bin>

From ezio.melotti at gmail.com  Sun Aug  1 22:01:52 2010
From: ezio.melotti at gmail.com (Ezio Melotti)
Date: Sun, 01 Aug 2010 23:01:52 +0300
Subject: [Python-Dev] No response to posts
In-Reply-To: <20100801174343.5612E200239@kimball.webabinitio.net>
References: <i32g9g$ouf$1@dough.gmane.org>	<AANLkTi=5xfXtYbRbe8ZD5XmG7vApWZhbnm-vk3qq13Xg@mail.gmail.com>	<i338g6$9o7$1@dough.gmane.org>	<AANLkTin7oUUcOZFqBQnRe+0PFSPj78bEtD9p179YMe4Z@mail.gmail.com>
	<20100801174343.5612E200239@kimball.webabinitio.net>
Message-ID: <4C55D2B0.6020703@gmail.com>

  On 01/08/2010 20.43, R. David Murray wrote:
> On Sun, 01 Aug 2010 21:28:05 +1000, Nick Coghlan<ncoghlan at gmail.com>  wrote:
>> On Sun, Aug 1, 2010 at 5:41 PM, Mark Lawrence<breamoreboy at yahoo.co.uk>  wrote:
>>> I plucked this figure out of the air thinking that if an issue was going to
>>> drop under the radar, this would be the most likely time. I was considering
>>> a worst case scenario where several core triage people are at a big Python
>>> event, others are on holiday [ shame on you :) ], some looking after the
>>> kids, yet more off sick etc. Hum, perhaps 24 hours is too soon, what a bout
>>> a week, opinions anybody? Notifications would go to the bugs mailing list
>>> and/or #python-dev. But this is hypothetical anyway if the message count of
>>> 1 query works. Only one way to find out, let's try it.
>> Perhaps just another number to track in the weekly bug summary?
> Better, a table section giving the bugids, titles, and URL.  Ezio just
> finished reworking the summary script to be more easily modified, so I
> bet he would find this easy to add at this point.
>
> --David
>
FWIW this morning I added a new version of the roundup-summary script 
[0] that includes a "Recent issues with no replies" table with bugids, 
titles and URLs. (I hope Guido doesn't mind if I used the time machine ;)

[0]: http://psf.upfronthosting.co.za/roundup/meta/issue284

From ziade.tarek at gmail.com  Sun Aug  1 22:37:47 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Sun, 1 Aug 2010 22:37:47 +0200
Subject: [Python-Dev] PEP 376 proposed changes for basic plugins support
Message-ID: <AANLkTinyjMkF2n91zS+48n6B_gkp9szW_bH0XJgTDh7D@mail.gmail.com>

Hello,

Here's a proposal to extend PEP 376 to support a basic plugins feature
-- you should read PEP 376 before reading this mail

It's basically Phillip's entry points, but with an activation flag,
and a per-user config file.

= adding a PLUGINS file =

A new file called 'PLUGINS' is added to the dist-info directory at
install time, and contains a list of plugins for the installed
distribution.

The file is a CSV file like the RECORD file, containing one plugin per
line. (see the RECORD file for details on the syntax)

A plugin is defined by :

- an application name : a string containing a name of a group of
plugins. It can be the name of the application that supports plugins,
  or any string. The recommended value is the distutils name of the
project, as it appears at PyPI.
  max length: 64, chars: [a-z0-9]

- a plugin type name: a string containing a name of a type of plugins.
It can be combined with the application name to create one class of
plugins
 for a given application. 64 chars [a-z0-9] -- default value 'plugin'

- a name: a string containing a name for the plugin. Combined with the
application name and plugin type, it defines this plugin. 64 chars
[a-z0-9]

- a description: a string describing the plugin. 256 chars.

- a state: 1 or 0. 1 means the plugin is activated, 0 means it's not activated

- a code link: a link to the plugin object (whether its a module,
class, object, etc). This link is the complete import path. For
example, a plugin class called
  "Foo" located in the "bar" module, located in the "baz" package, is
noted: "baz.bar.Foo"  (the project that uses plugins is responsible
for iteratting, picking and loading plugins)

= PLUGINS example =

Here's an example of a PLUGINS file for a 'UnittestPlugins' project
that implements 2 unitest2 plugins:

  unittest2;plugin;pep8;pep8 checker;1;unittestplugins.pep8
  unittest2;plugin;debugger,Cool debugger;1;unittestplugins.debug

= per-user plugins =

A plugin can be activated or disable globally, but a user should be
able to configure them differently.

A ini-like plugins.cfg file is added per-user (its location to be
defined -- its discussed in another thread) and
overrides the state of the installed plugin. It provides a value for
each app.type.name plugin.

  [plugins]
  unittest2.plugin.pep8 = 0
  distutils2.commands.funkycommand = 0

Notice that the user can have plugins provided by distributions
installed in his own per-user site packages.

= Implementation =

I don't want to go into great details here yet, until we get a
consensus on the PLUGINS file.

But basically we will add these features in pkgutil:

- browse plugins and get their info.
- activate/disable a plugin, by writing its state
- load a plugin and return it by importing the 'code link'

and in distutils2:

- let the user configure if plugins are automatically activated when
the project is installed
- provide a end-user script to browse plugins
- provide a way to define plugins statically in setup.cfg


Regards
Tarek

-- 
Tarek Ziad? | http://ziade.org

From ncoghlan at gmail.com  Sun Aug  1 23:55:40 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 2 Aug 2010 07:55:40 +1000
Subject: [Python-Dev] PEP 376 proposed changes for basic plugins support
In-Reply-To: <AANLkTinyjMkF2n91zS+48n6B_gkp9szW_bH0XJgTDh7D@mail.gmail.com>
References: <AANLkTinyjMkF2n91zS+48n6B_gkp9szW_bH0XJgTDh7D@mail.gmail.com>
Message-ID: <AANLkTik=+9LnomC3+kDFh_TJeHGUv51jk+rFEu35pxBQ@mail.gmail.com>

On Mon, Aug 2, 2010 at 6:37 AM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
> Hello,
>
> Here's a proposal to extend PEP 376 to support a basic plugins feature
> -- you should read PEP 376 before reading this mail
>
> It's basically Phillip's entry points, but with an activation flag,
> and a per-user config file.
>
> = adding a PLUGINS file =
>
> A new file called 'PLUGINS' is added to the dist-info directory at
> install time, and contains a list of plugins for the installed
> distribution.
>
> The file is a CSV file like the RECORD file, containing one plugin per
> line. (see the RECORD file for details on the syntax)
>
> A plugin is defined by :
>
> - an application name : a string containing a name of a group of
> plugins. It can be the name of the application that supports plugins,
> ?or any string. The recommended value is the distutils name of the
> project, as it appears at PyPI.
> ?max length: 64, chars: [a-z0-9]
>
> - a plugin type name: a string containing a name of a type of plugins.
> It can be combined with the application name to create one class of
> plugins
> ?for a given application. 64 chars [a-z0-9] -- default value 'plugin'
>
> - a name: a string containing a name for the plugin. Combined with the
> application name and plugin type, it defines this plugin. 64 chars
> [a-z0-9]
>
> - a description: a string describing the plugin. 256 chars.
>
> - a state: 1 or 0. 1 means the plugin is activated, 0 means it's not activated
>
> - a code link: a link to the plugin object (whether its a module,
> class, object, etc). This link is the complete import path. For
> example, a plugin class called
> ?"Foo" located in the "bar" module, located in the "baz" package, is
> noted: "baz.bar.Foo" ?(the project that uses plugins is responsible
> for iteratting, picking and loading plugins)

Is dealing with name conflicts left up to the application?

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From phd at phd.pp.ru  Sun Aug  1 23:58:18 2010
From: phd at phd.pp.ru (Oleg Broytman)
Date: Mon, 2 Aug 2010 01:58:18 +0400
Subject: [Python-Dev] Metadata: charset (was: PEP 376 proposed
	changes	for basic plugins support)
In-Reply-To: <AANLkTinyjMkF2n91zS+48n6B_gkp9szW_bH0XJgTDh7D@mail.gmail.com>
References: <AANLkTinyjMkF2n91zS+48n6B_gkp9szW_bH0XJgTDh7D@mail.gmail.com>
Message-ID: <20100801215818.GA22377@phd.pp.ru>

On Sun, Aug 01, 2010 at 10:37:47PM +0200, Tarek Ziad? wrote:
> The file is a CSV file

   In what encoding (charset)? I quickly skimmed over PEPs 262, 241, 314
and 376, but didn't encountered any mention of the words "encoding" or
"charset". Documentation for the "csv" module also doesn't provide any
clear indication of encoding/charset.

Oleg.
-- 
     Oleg Broytman            http://phd.pp.ru/            phd at phd.pp.ru
           Programmers don't die, they just GOSUB without RETURN.

From ziade.tarek at gmail.com  Mon Aug  2 00:07:54 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 2 Aug 2010 00:07:54 +0200
Subject: [Python-Dev] PEP 376 proposed changes for basic plugins support
In-Reply-To: <AANLkTik=+9LnomC3+kDFh_TJeHGUv51jk+rFEu35pxBQ@mail.gmail.com>
References: <AANLkTinyjMkF2n91zS+48n6B_gkp9szW_bH0XJgTDh7D@mail.gmail.com>
	<AANLkTik=+9LnomC3+kDFh_TJeHGUv51jk+rFEu35pxBQ@mail.gmail.com>
Message-ID: <AANLkTi=5bbYCfQ7A9r=sptMb9sSnN9FCLhywdYo1H3Qh@mail.gmail.com>

On Sun, Aug 1, 2010 at 11:55 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
...
> Is dealing with name conflicts left up to the application?

When an application iterates on the plugins that are supposely built
for it, it will probably expect a single type of object. For instance
unitest2 will want classes that are overriding its Plugin base class.
So it should be able to drop objects that are not compliant with its
system.

Now, since the distutils id at PyPI is unique, using it for the
application name in the plugin like I proposed,
should also help preventing this issue.

From ziade.tarek at gmail.com  Mon Aug  2 00:11:06 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 2 Aug 2010 00:11:06 +0200
Subject: [Python-Dev] Metadata: charset (was: PEP 376 proposed changes
	for basic plugins support)
In-Reply-To: <20100801215818.GA22377@phd.pp.ru>
References: <AANLkTinyjMkF2n91zS+48n6B_gkp9szW_bH0XJgTDh7D@mail.gmail.com>
	<20100801215818.GA22377@phd.pp.ru>
Message-ID: <AANLkTikvBNzhuD6rvUBK8FufE0QP+Jj6qKCiBN3-v9Ec@mail.gmail.com>

On Sun, Aug 1, 2010 at 11:58 PM, Oleg Broytman <phd at phd.pp.ru> wrote:
> On Sun, Aug 01, 2010 at 10:37:47PM +0200, Tarek Ziad? wrote:
>> The file is a CSV file
>
> ? In what encoding (charset)? I quickly skimmed over PEPs 262, 241, 314
> and 376, but didn't encountered any mention of the words "encoding" or
> "charset". Documentation for the "csv" module also doesn't provide any
> clear indication of encoding/charset.

utf-8. I'll add this info in PEP 376 -- Thanks

>
> Oleg.
> --
> ? ? Oleg Broytman ? ? ? ? ? ?http://phd.pp.ru/ ? ? ? ? ? ?phd at phd.pp.ru
> ? ? ? ? ? Programmers don't die, they just GOSUB without RETURN.
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/ziade.tarek%40gmail.com
>



-- 
Tarek Ziad? | http://ziade.org

From phd at phd.pp.ru  Mon Aug  2 00:16:33 2010
From: phd at phd.pp.ru (Oleg Broytman)
Date: Mon, 2 Aug 2010 02:16:33 +0400
Subject: [Python-Dev] Metadata: charset
In-Reply-To: <AANLkTikvBNzhuD6rvUBK8FufE0QP+Jj6qKCiBN3-v9Ec@mail.gmail.com>
References: <AANLkTinyjMkF2n91zS+48n6B_gkp9szW_bH0XJgTDh7D@mail.gmail.com>
	<20100801215818.GA22377@phd.pp.ru>
	<AANLkTikvBNzhuD6rvUBK8FufE0QP+Jj6qKCiBN3-v9Ec@mail.gmail.com>
Message-ID: <20100801221633.GB22377@phd.pp.ru>

On Mon, Aug 02, 2010 at 12:11:06AM +0200, Tarek Ziad? wrote:
> On Sun, Aug 1, 2010 at 11:58 PM, Oleg Broytman <phd at phd.pp.ru> wrote:
> > On Sun, Aug 01, 2010 at 10:37:47PM +0200, Tarek Ziad? wrote:
> >> The file is a CSV file
> >
> > ? In what encoding (charset)? I quickly skimmed over PEPs 262, 241, 314
> > and 376, but didn't encountered any mention of the words "encoding" or
> > "charset". Documentation for the "csv" module also doesn't provide any
> > clear indication of encoding/charset.
> 
> utf-8. I'll add this info in PEP 376 -- Thanks

   Thank you for the clarification!

Oleg.
-- 
     Oleg Broytman            http://phd.pp.ru/            phd at phd.pp.ru
           Programmers don't die, they just GOSUB without RETURN.

From fuzzyman at voidspace.org.uk  Mon Aug  2 01:11:11 2010
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Mon, 02 Aug 2010 00:11:11 +0100
Subject: [Python-Dev] PEP 376 proposed changes for basic plugins support
In-Reply-To: <AANLkTinyjMkF2n91zS+48n6B_gkp9szW_bH0XJgTDh7D@mail.gmail.com>
References: <AANLkTinyjMkF2n91zS+48n6B_gkp9szW_bH0XJgTDh7D@mail.gmail.com>
Message-ID: <4C55FF0F.3010702@voidspace.org.uk>

On 01/08/2010 21:37, Tarek Ziad? wrote:
> Hello,
>
> Here's a proposal to extend PEP 376 to support a basic plugins feature
> -- you should read PEP 376 before reading this mail
>
> It's basically Phillip's entry points, but with an activation flag,
> and a per-user config file.
>
> = adding a PLUGINS file =
>
> A new file called 'PLUGINS' is added to the dist-info directory at
> install time, and contains a list of plugins for the installed
> distribution.
>
> The file is a CSV file like the RECORD file, containing one plugin per
> line. (see the RECORD file for details on the syntax)
>
> A plugin is defined by :
>
> - an application name : a string containing a name of a group of
> plugins. It can be the name of the application that supports plugins,
>    or any string. The recommended value is the distutils name of the
> project, as it appears at PyPI.
>    max length: 64, chars: [a-z0-9]
>
> - a plugin type name: a string containing a name of a type of plugins.
> It can be combined with the application name to create one class of
> plugins
>   for a given application. 64 chars [a-z0-9] -- default value 'plugin'
>
> - a name: a string containing a name for the plugin. Combined with the
> application name and plugin type, it defines this plugin. 64 chars
> [a-z0-9]
>
> - a description: a string describing the plugin. 256 chars.
>
> - a state: 1 or 0. 1 means the plugin is activated, 0 means it's not activated
>
> - a code link: a link to the plugin object (whether its a module,
> class, object, etc). This link is the complete import path. For
> example, a plugin class called
>    "Foo" located in the "bar" module, located in the "baz" package, is
> noted: "baz.bar.Foo"  (the project that uses plugins is responsible
> for iteratting, picking and loading plugins)
>
> = PLUGINS example =
>
> Here's an example of a PLUGINS file for a 'UnittestPlugins' project
> that implements 2 unitest2 plugins:
>
>    unittest2;plugin;pep8;pep8 checker;1;unittestplugins.pep8
>    unittest2;plugin;debugger,Cool debugger;1;unittestplugins.debug
>
>    

This seems fine; I mean it isn't written directly by humans or intended 
to be read directly by humans I guess. :-)

(Users will specify plugins in the setup metadata and this will be 
written on install by distutils2 - right?.)

> = per-user plugins =
>
> A plugin can be activated or disable globally, but a user should be
> able to configure them differently.
>
> A ini-like plugins.cfg file is added per-user (its location to be
> defined -- its discussed in another thread) and
> overrides the state of the installed plugin. It provides a value for
> each app.type.name plugin.
>
>    [plugins]
>    unittest2.plugin.pep8 = 0
>    distutils2.commands.funkycommand = 0
>
> Notice that the user can have plugins provided by distributions
> installed in his own per-user site packages.
>
>    

I don't think that unittest would use a distutils2 (or pkgutil) supplied 
API for activation. unittest needs *separate* per user and per project 
activation (a plugin active for a project may not be needed in other 
projects and so won't be enabled at the user level for example). 
unittest also needs plugin *configuration* and it makes sense to keep 
configuration and activation in the same place.

The interesting part of this proposal for unittest is the plugin discovery.

unittest will use the two config file solution (location of user config 
still to be determined) and probably a "plugins" subcommand (eventually) 
to manage the config file from the command line.

On the other hand the activation is likely to be wanted by other 
projects that use plugins and it certainly doesn't hurt unittest.

> = Implementation =
>
> I don't want to go into great details here yet, until we get a
> consensus on the PLUGINS file.
>
> But basically we will add these features in pkgutil:
>
> - browse plugins and get their info.
>    
Yes, great.

> - activate/disable a plugin, by writing its state
> - load a plugin and return it by importing the 'code link'
>
>    
Also great.

> and in distutils2:
>
> - let the user configure if plugins are automatically activated when
> the project is installed
> - provide a end-user script to browse plugins
> - provide a way to define plugins statically in setup.cfg
>
>    
All sounds good to me.

Michael

> Regards
> Tarek
>
>    


-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (?BOGUS AGREEMENTS?) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.



From tjreedy at udel.edu  Mon Aug  2 01:14:17 2010
From: tjreedy at udel.edu (Terry Reedy)
Date: Sun, 01 Aug 2010 19:14:17 -0400
Subject: [Python-Dev] No response to posts
In-Reply-To: <4C555E24.9040007@netwok.org>
References: <i32g9g$ouf$1@dough.gmane.org>	<AANLkTi=5xfXtYbRbe8ZD5XmG7vApWZhbnm-vk3qq13Xg@mail.gmail.com>	<i338g6$9o7$1@dough.gmane.org>	<AANLkTin7oUUcOZFqBQnRe+0PFSPj78bEtD9p179YMe4Z@mail.gmail.com>
	<4C555E24.9040007@netwok.org>
Message-ID: <i34v48$8lc$1@dough.gmane.org>

On 8/1/2010 7:44 AM, ?ric Araujo wrote:

+1 On a prebuilt search

This is not as easy as it seems.
A nosy count of 1 misses posts where someone added themself as nosy 
without saying anything, waiting for someone else to answer (and maybe 
no one ever did). A message count of 1 misses posts where a person 
follows up with a correction (because he cannot edit!) or addition.
nosy = 1 or message = 1 would be better, and one cannot do that from 
search form, which, ANDS things together. Can a custom sql query do an OR?

>> Perhaps just another number to track in the weekly bug summary?
>
> *puts bug person hat on* I made the same suggestion to Ezio, so +1

If Friday report marked issues without responses, I would make a special 
effort to look at those.

-- 
Terry Jan Reedy



From tjreedy at udel.edu  Mon Aug  2 01:17:58 2010
From: tjreedy at udel.edu (Terry Reedy)
Date: Sun, 01 Aug 2010 19:17:58 -0400
Subject: [Python-Dev] Is it intentional that "sys.__debug__ = 1"
 isillegal in Python 2.7?
In-Reply-To: <AANLkTiminaKLLxs1r1r1Rd65jeh9EZ6SRQe9tuwOQER0@mail.gmail.com>
References: <20100730162608.7315c3a5@heresy>	<AANLkTi=NVFW+bJFZZBvzRKu75YPtyx-9YEG5=E_kHb6G@mail.gmail.com>
	<20100730165325.49414a21@heresy>	<AANLkTi=2=qSUnNPFm_g3T0EQ8sbn4HSS3NO9DaH8=iKi@mail.gmail.com>
	<D2F744D05ED19D45A4A7757F49274A8B03AFF9FB@IAD-WPRD-XCHB01.corp.verio.net>	<20100731124122.67890e85@heresy>
	<AANLkTiminaKLLxs1r1r1Rd65jeh9EZ6SRQe9tuwOQER0@mail.gmail.com>
Message-ID: <i34vb2$8lc$2@dough.gmane.org>

On 7/31/2010 5:02 PM, Guido van Rossum wrote:

> But yes, the docs should clarify that *any* use of __*__ names, in
> *any* context, that does not follow explicitly documented use, is
> subject to breakage without warning.

http://bugs.python.org/issue9451
Strengthen __*__ system name warning

My suggested new version, incorporating Guido's sentence:

System-defined names. These names are defined by the interpreter and its 
implementation (including the standard library). Current system names 
are discussed in the Special method names section and elsewhere. More 
will likely be defined in future versions of Python. *Any* use of __*__ 
names, in any* context, that does not follow explicitly documented use, 
is subject to breakage without warning.

-- 
Terry Jan Reedy


From rrr at ronadam.com  Mon Aug  2 01:37:51 2010
From: rrr at ronadam.com (Ron Adam)
Date: Sun, 01 Aug 2010 18:37:51 -0500
Subject: [Python-Dev] No response to posts
In-Reply-To: <i34v48$8lc$1@dough.gmane.org>
References: <i32g9g$ouf$1@dough.gmane.org>	<AANLkTi=5xfXtYbRbe8ZD5XmG7vApWZhbnm-vk3qq13Xg@mail.gmail.com>	<i338g6$9o7$1@dough.gmane.org>	<AANLkTin7oUUcOZFqBQnRe+0PFSPj78bEtD9p179YMe4Z@mail.gmail.com>	<4C555E24.9040007@netwok.org>
	<i34v48$8lc$1@dough.gmane.org>
Message-ID: <i350gg$blm$1@dough.gmane.org>



On 08/01/2010 06:14 PM, Terry Reedy wrote:
> On 8/1/2010 7:44 AM, ?ric Araujo wrote:
>
> +1 On a prebuilt search
>
> This is not as easy as it seems.
> A nosy count of 1 misses posts where someone added themself as nosy
> without saying anything, waiting for someone else to answer (and maybe
> no one ever did). A message count of 1 misses posts where a person
> follows up with a correction (because he cannot edit!) or addition.
> nosy = 1 or message = 1 would be better, and one cannot do that from
> search form, which, ANDS things together. Can a custom sql query do an OR?

There is an activity field which gets any issues with activity on a 
specific day.  I'm not sure how useful that is. <shrug>

Something that may be more useful, is a "no activity" search field with 
choices of day, week, month, year, etc... and make the output sortable on 
time without activity.

That not only would cover the short term cases of no response, but also the 
longer term items that slip though the cracks.

Ron



From ziade.tarek at gmail.com  Mon Aug  2 01:46:03 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 2 Aug 2010 01:46:03 +0200
Subject: [Python-Dev] PEP 376 proposed changes for basic plugins support
In-Reply-To: <4C55FF0F.3010702@voidspace.org.uk>
References: <AANLkTinyjMkF2n91zS+48n6B_gkp9szW_bH0XJgTDh7D@mail.gmail.com>
	<4C55FF0F.3010702@voidspace.org.uk>
Message-ID: <AANLkTim1af-zWEYF4U-vTr6d+8HkqFCycMVmQYsqpDcN@mail.gmail.com>

On Mon, Aug 2, 2010 at 1:11 AM, Michael Foord <fuzzyman at voidspace.org.uk> wrote:
> This seems fine; I mean it isn't written directly by humans or intended to
> be read directly by humans I guess. :-)
>
> (Users will specify plugins in the setup metadata and this will be written
> on install by distutils2 - right?.)

Yes, exactly

>
>> = per-user plugins =
>>
>> A plugin can be activated or disable globally, but a user should be
>> able to configure them differently.
>>
>> A ini-like plugins.cfg file is added per-user (its location to be
>> defined -- its discussed in another thread) and
>> overrides the state of the installed plugin. It provides a value for
>> each app.type.name plugin.
>>
>> ? [plugins]
>> ? unittest2.plugin.pep8 = 0
>> ? distutils2.commands.funkycommand = 0
>>
>> Notice that the user can have plugins provided by distributions
>> installed in his own per-user site packages.
>>
>>
>
> I don't think that unittest would use a distutils2 (or pkgutil) supplied API
> for activation.

But the discovery API you will use might just simply filter out
disabled plugins.

In any case, if unittest2 tries to bypass this activation flag I don't
see the point of having it there
since its purpose is to let the end-user deactivate a plugin that
might be used by several applications.


> unittest needs *separate* per user and per project
> activation (a plugin active for a project may not be needed in other
> projects and so won't be enabled at the user level for example).

And sharing plugins across apps is a use case too: Nose could use
unittest2 plugins and vice-versa.

Tarek

From fuzzyman at voidspace.org.uk  Mon Aug  2 01:56:19 2010
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Mon, 02 Aug 2010 00:56:19 +0100
Subject: [Python-Dev] PEP 376 proposed changes for basic plugins support
In-Reply-To: <AANLkTim1af-zWEYF4U-vTr6d+8HkqFCycMVmQYsqpDcN@mail.gmail.com>
References: <AANLkTinyjMkF2n91zS+48n6B_gkp9szW_bH0XJgTDh7D@mail.gmail.com>	<4C55FF0F.3010702@voidspace.org.uk>
	<AANLkTim1af-zWEYF4U-vTr6d+8HkqFCycMVmQYsqpDcN@mail.gmail.com>
Message-ID: <4C5609A3.3090008@voidspace.org.uk>

On 02/08/2010 00:46, Tarek Ziad? wrote:
> [snip...]
>> I don't think that unittest would use a distutils2 (or pkgutil) supplied API
>> for activation.
>>      
> But the discovery API you will use might just simply filter out
> disabled plugins.
>    

I did consider asking this but thought it was a silly question - there 
*must* be an API to get all plugins otherwise applications couldn't 
activate or deactivate them (or allow their users to do this) - and then 
how could users activate a non-active plugin? (I guess there could be 
private APIs that only distutils2 is supposed to use, or the script that 
you mentioned.)

On the other hand if the user has deactivated a plugin through 
distutils2 I have no problem with it not being available to unittest.

> In any case, if unittest2 tries to bypass this activation flag I don't
> see the point of having it there
> since its purpose is to let the end-user deactivate a plugin that
> might be used by several applications.
>
>    

Right. As I explained, I don't think unittest *can* use this mechanism 
since it can have plugins active for one project but not for another. I 
would really have no problem with this machinery existing, but it 
wouldn't be useful/usable by unittest for plugins.

It sounds like it can fairly easily be bolted on as a new feature set 
later *anyway*, so dropping it for now simplifies the initial 
implementation.

Wouldn't that mean that distutils2 would still need its *own* system for 
telling whether or not installed plugins are active? So maybe you have 
to build it anyway.

>> unittest needs *separate* per user and per project
>> activation (a plugin active for a project may not be needed in other
>> projects and so won't be enabled at the user level for example).
>>      
> And sharing plugins across apps is a use case too: Nose could use
> unittest2 plugins and vice-versa.
>    

Hehe, well - that's a different story...

Michael

> Tarek
>    


-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (?BOGUS AGREEMENTS?) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.



From ziade.tarek at gmail.com  Mon Aug  2 02:03:53 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 2 Aug 2010 02:03:53 +0200
Subject: [Python-Dev] PEP 376 proposed changes for basic plugins support
In-Reply-To: <4C5609A3.3090008@voidspace.org.uk>
References: <AANLkTinyjMkF2n91zS+48n6B_gkp9szW_bH0XJgTDh7D@mail.gmail.com>
	<4C55FF0F.3010702@voidspace.org.uk>
	<AANLkTim1af-zWEYF4U-vTr6d+8HkqFCycMVmQYsqpDcN@mail.gmail.com>
	<4C5609A3.3090008@voidspace.org.uk>
Message-ID: <AANLkTimU-OUh8fzFoRvHMsQOqVa+jsFTfPyZKeY=heVg@mail.gmail.com>

On Mon, Aug 2, 2010 at 1:56 AM, Michael Foord <fuzzyman at voidspace.org.uk> wrote:
> On 02/08/2010 00:46, Tarek Ziad? wrote:
>>
>> [snip...]
>>>
>>> I don't think that unittest would use a distutils2 (or pkgutil) supplied
>>> API
>>> for activation.
>>>
>>
>> But the discovery API you will use might just simply filter out
>> disabled plugins.
>>
>
> I did consider asking this but thought it was a silly question - there
> *must* be an API to get all plugins otherwise applications couldn't activate
> or deactivate them (or allow their users to do this) - and then how could
> users activate a non-active plugin? (I guess there could be private APIs
> that only distutils2 is supposed to use, or the script that you mentioned.)

yes, there will be a way to retrieve them all

...
> It sounds like it can fairly easily be bolted on as a new feature set later
> *anyway*, so dropping it for now simplifies the initial implementation.

but then we would be back to the problem mentioned about entry points:
installing projects can implicitly add a plugin and activate it, and break
existing applications that iterate over entry points without further
configuration. So being able to disable plugins from the beginning seems
important to me

From ilya.sandler at gmail.com  Mon Aug  2 02:10:04 2010
From: ilya.sandler at gmail.com (Ilya Sandler)
Date: Sun, 1 Aug 2010 17:10:04 -0700
Subject: [Python-Dev] pdb mini-sprint report and questions
In-Reply-To: <i2vkq0$llq$1@dough.gmane.org>
References: <i2vkq0$llq$1@dough.gmane.org>
Message-ID: <AANLkTikSXtXc=0Xz8e6SL6HXReLUJOAkCtFdnr2DbusV@mail.gmail.com>

Hello,

I'm the submitter of the original patch and would like to help with it if I can.

> One issue that's not yet closed is #7245, which adds a (very nice IMO)
> feature: when you press Ctrl-C while the program being debugged runs,
> you will not get a traceback but execution is suspended, and you can
> debug from the current point of execution -- just like in gdb.
>
> However, there were apparently issues with some of the buildbots when
> the patch was applied for a short time. ?I also don't know how and if
> it works on Windows, so I'd need some helpful people testing it.

For whatever it's worth, it worked for me with python trunk (2.x) on
Vista, when I tried it manually.  But I don't know how to implement
the unit test there (subprocess module doesn't support sending SIGINT
programmatically on windows either). So the test_pdb2 test does not
check signal behavior on Windows platforms.

Buildbot failures are still a total mystery for me ;-):  the failures
were happening elsewhere and seemed to be unrelated to test_pdb2. Is
there any other way to apply the patch and run the tests on failing
platforms?

Ilya

>
> Another question is about a feature of pdb++ that I personally would
> like, but imagine would make others unhappy: ?one-letter abbreviations
> of commands such as c(ontinue) or l(ist) are also often-used variable
> names, so they are frequently typed without the required "!" or "print"
> that would distinguish them from the command, and the command is
> actually executed. ?The feature in question would default to printing
> the variable in cases where one exists -- handy enough or too
> inconsistent?
>
> Also, are there any other features you would like to see? ?One feature
> of pdb++ that is general enough and has no dependencies would be watch
> expressions...
>
> Georg
>
> --
> Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
> Four shall be the number of spaces thou shalt indent, and the number of thy
> indenting shall be four. Eight shalt thou not indent, nor either indent thou
> two, excepting that thou then proceed to four. Tabs are right out.
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/ilya.sandler%40gmail.com
>

From fuzzyman at voidspace.org.uk  Mon Aug  2 02:15:04 2010
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Mon, 02 Aug 2010 01:15:04 +0100
Subject: [Python-Dev] PEP 376 proposed changes for basic plugins support
In-Reply-To: <AANLkTimU-OUh8fzFoRvHMsQOqVa+jsFTfPyZKeY=heVg@mail.gmail.com>
References: <AANLkTinyjMkF2n91zS+48n6B_gkp9szW_bH0XJgTDh7D@mail.gmail.com>	<4C55FF0F.3010702@voidspace.org.uk>	<AANLkTim1af-zWEYF4U-vTr6d+8HkqFCycMVmQYsqpDcN@mail.gmail.com>	<4C5609A3.3090008@voidspace.org.uk>
	<AANLkTimU-OUh8fzFoRvHMsQOqVa+jsFTfPyZKeY=heVg@mail.gmail.com>
Message-ID: <4C560E08.50207@voidspace.org.uk>

On 02/08/2010 01:03, Tarek Ziad? wrote:
> On Mon, Aug 2, 2010 at 1:56 AM, Michael Foord<fuzzyman at voidspace.org.uk>  wrote:
>    
>> On 02/08/2010 00:46, Tarek Ziad? wrote:
>>      
>>> [snip...]
>>>        
>>>> I don't think that unittest would use a distutils2 (or pkgutil) supplied
>>>> API
>>>> for activation.
>>>>
>>>>          
>>> But the discovery API you will use might just simply filter out
>>> disabled plugins.
>>>
>>>        
>> I did consider asking this but thought it was a silly question - there
>> *must* be an API to get all plugins otherwise applications couldn't activate
>> or deactivate them (or allow their users to do this) - and then how could
>> users activate a non-active plugin? (I guess there could be private APIs
>> that only distutils2 is supposed to use, or the script that you mentioned.)
>>      
> yes, there will be a way to retrieve them all
>
> ...
>    
>> It sounds like it can fairly easily be bolted on as a new feature set later
>> *anyway*, so dropping it for now simplifies the initial implementation.
>>      
> but then we would be back to the problem mentioned about entry points:
> installing projects can implicitly add a plugin and activate it, and break
> existing applications that iterate over entry points without further
> configuration. So being able to disable plugins from the beginning seems
> important to me
>    

I agree it sounds like an important feature - a point of control for the 
user or the system as you said on irc. I still don't think unittest 
*can* use it, but I'm quite happy with the fact that if a user 
deactivates a plugin through distutils2 then it is no longer *available* 
to unittest.

Michael

-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (?BOGUS AGREEMENTS?) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.



From pje at telecommunity.com  Mon Aug  2 03:06:20 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Sun, 01 Aug 2010 21:06:20 -0400
Subject: [Python-Dev] PEP 376 proposed changes for basic plugins support
In-Reply-To: <AANLkTimU-OUh8fzFoRvHMsQOqVa+jsFTfPyZKeY=heVg@mail.gmail.c
 om>
References: <AANLkTinyjMkF2n91zS+48n6B_gkp9szW_bH0XJgTDh7D@mail.gmail.com>
	<4C55FF0F.3010702@voidspace.org.uk>
	<AANLkTim1af-zWEYF4U-vTr6d+8HkqFCycMVmQYsqpDcN@mail.gmail.com>
	<4C5609A3.3090008@voidspace.org.uk>
	<AANLkTimU-OUh8fzFoRvHMsQOqVa+jsFTfPyZKeY=heVg@mail.gmail.com>
Message-ID: <20100802010616.5FD133A4758@sparrow.telecommunity.com>

At 02:03 AM 8/2/2010 +0200, Tarek Ziad? wrote:
>but then we would be back to the problem mentioned about entry points:
>installing projects can implicitly add a plugin and activate it, and break
>existing applications that iterate over entry points without further
>configuration. So being able to disable plugins from the beginning seems
>important to me

So which are these apps that don't allow configuration, and which are 
the plugins that break them?  Have the issues been reported so that 
the authors can fix them?

ISTM that the issue can only arise in cases where you are installing 
plugins to a *global* environment, rather than to an environment 
specific to the application.

In the case of setuptools, for example, it's expected that a project 
will use 'setup_requires' to identify the plugins it wishes to use, 
apart from any that were intentionally installed globally.  (The 
requested plugins are then added to sys.path only for the duration of 
the setup script execution.)

Other applications have plugin directories where their plugins are to 
be installed, and still others have explicit configuration to enable 
named plugins.

Even in the worst-case scenario, where an app has no plugin 
configuration and no private plugin directory, you can still control 
plugin availability by installing plugins to the directory where the 
application's main script is located, or point PYTHONPATH to point to 
a directory you've chosen to hold the plugins of your choice.

So without specific examples of why this is a problem, it's hard to 
see why a special Python-specific set of configuration files is 
needed to resolve it, vs. say, encouraging application authors to use 
the available alternatives for doing plugin directories, config files, etc.


From benjamin at python.org  Mon Aug  2 04:54:18 2010
From: benjamin at python.org (Benjamin Peterson)
Date: Sun, 1 Aug 2010 21:54:18 -0500
Subject: [Python-Dev] No response to posts
In-Reply-To: <4C54C5A4.6080409@netwok.org>
References: <i32g9g$ouf$1@dough.gmane.org>
	<4C54C5A4.6080409@netwok.org>
Message-ID: <AANLkTinpB7yVhMSQ=Q9hMCA+SnF4p+zNH98-GZd4ZP+w@mail.gmail.com>

2010/7/31 ?ric Araujo <winston at netwok.org>:
> Good call.
>
> Alternative idea: Have a new status ?unread? to make searching easier
> for bug people. Or a predefined custom search for nosy_count == 1.

Please, let's stop messing with the tracker for everything. I think
the current set up works reasonably well, and we should focus on the
real problem: manpower



-- 
Regards,
Benjamin

From benjamin at python.org  Mon Aug  2 04:56:57 2010
From: benjamin at python.org (Benjamin Peterson)
Date: Sun, 1 Aug 2010 21:56:57 -0500
Subject: [Python-Dev] Is it intentional that "sys.__debug__ = 1" is
	illegal in Python 2.7?
In-Reply-To: <20100730162608.7315c3a5@heresy>
References: <20100730162608.7315c3a5@heresy>
Message-ID: <AANLkTinvU-QwqP6G2TPH-cROeUqUhDt3OsA1Ce61iwdy@mail.gmail.com>

2010/7/30 Barry Warsaw <barry at python.org>:
>
> It looks like Benjamin's change in r67171 was the relevant diff.

The reason behind this was to make __debug__ assignment consistent
with that of other reserved names. For example, x.None = 3 raised and
thus, so should x.__debug__ = 3.



-- 
Regards,
Benjamin

From benjamin at python.org  Mon Aug  2 05:01:25 2010
From: benjamin at python.org (Benjamin Peterson)
Date: Sun, 1 Aug 2010 22:01:25 -0500
Subject: [Python-Dev] [RELEASED] Python 3.2 alpha 1
In-Reply-To: <4C55409B.5000409@python.org>
References: <4C55409B.5000409@python.org>
Message-ID: <AANLkTik5JUSkTem0myE-2MWJ3i_m3MFthr4sKp35kbOz@mail.gmail.com>

Hey, Georg! Congrats on your first release!

2010/8/1 Georg Brandl <georg at python.org>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On behalf of the Python development team, I'm happy to announce the
> first alpha preview release of Python 3.2.
>
> Python 3.2 is a continuation of the efforts to improve and stabilize the
> Python 3.x line. ?Since the final release of Python 2.7, the 2.x line
> will only receive bugfixes, and new features are developed for 3.x only.
>
> Since PEP 3003, the Moratorium on Language Changes, is in effect, there
> are no changes in Python's syntax and built-in types in Python 3.2.
> Development efforts concentrated on the standard library and support for
> porting code to Python 3. ?Highlights are:
>
> * numerous improvements to the unittest module
> * PEP 3147, support for .pyc repository directories
> * an overhauled GIL implementation that reduces contention
> * many consistency and behavior fixes for numeric operations
> * countless fixes regarding string/unicode issues; among them full
> ?support for a bytes environment (filenames, environment variables)
> * a sysconfig module to access configuration information
> * a pure-Python implementation of the datetime module
> * additions to the shutil module, among them archive file support
> * improvements to pdb, the Python debugger
>
> For an extensive list of changes in 3.2, see Misc/NEWS in the Python
> distribution.
>
> To download Python 3.2 visit:
>
> ? ? http://www.python.org/download/releases/3.2/
>
> 3.2 documentation can be found at:
>
> ? ? http://docs.python.org/3.2/
>
> Please consider trying Python 3.2 with your code and reporting any bugs
> you may notice to:
>
> ? ? http://bugs.python.org/
>
>
> Enjoy!
>
> - --
> Georg Brandl, Release Manager
> georg at python.org
> (on behalf of the entire python-dev team and 3.2's contributors)
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.16 (GNU/Linux)
>
> iEYEARECAAYFAkxVQJsACgkQN9GcIYhpnLBxIgCcCiVu/QUkFf0bYM2Vmi8St3mZ
> 2N4An04q36lr47OA+bslqG/4Zj7ZwVOX
> =iL8N
> -----END PGP SIGNATURE-----
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/benjamin%40python.org
>



-- 
Regards,
Benjamin

From guido at python.org  Mon Aug  2 06:24:10 2010
From: guido at python.org (Guido van Rossum)
Date: Sun, 1 Aug 2010 21:24:10 -0700
Subject: [Python-Dev] Yield-From Implementation Updated for Python 3
In-Reply-To: <20100801181619.537B13A4175@sparrow.telecommunity.com>
References: <4C552850.8020406@canterbury.ac.nz>
	<AANLkTin0S5R9qAMoo4i3-E1=d1ZJ8-5=DScsee1Ljtcr@mail.gmail.com> 
	<20100801181619.537B13A4175@sparrow.telecommunity.com>
Message-ID: <AANLkTikX6vHmj=wFzny-zd=dVU1Qgr3x-+8ScMak=toP@mail.gmail.com>

On Sun, Aug 1, 2010 at 11:16 AM, P.J. Eby <pje at telecommunity.com> wrote:
> Just so you know, you don't need to wait for this to be added to Python in
> order to have such a construct; it just won't have the extra syntax sugar.
> ?See the sample code I posted here using a "@From.container" decorator, and
> a "yield From()" call:
>
> ?http://mail.python.org/pipermail/python-dev/2010-July/102320.html
>
> This code effectively reduces your generator nesting depth to a constant, no
> matter how deeply you nest sub-generator invocations. ?It's not as efficient
> as the equivalent C implementation, but if you're actually being affected by
> nesting overhead now, it will nonetheless provide you with some immediate
> relief, if you backport it to 2.x code. ?(It's not very 3.x-ish as it sits,
> really.)

Hi Phillip,

Your code is fiendishly clever (and I mean that as a compliment). Even
though only a few weeks ago I wrote a trampoline along these lines
(more similar to the one in PEP 342, example 3, but extended to
support async I/O), I don't understand all the details and corner
cases (e.g. the concatenation of stacks, which seems to have to do
with the special-casing of From objects in __new__) but I trust that
it works.

I am curious whether, if you need a trampoline for async I/O anyway,
there would be a swaying argument for integrating this functionality
into the general trampoline (as in the PEP 342 example), or whether it
would be better to separate the async I/O trampoline from the "From"
trampoline. The latter would in a sense be more future-proof because
once PEP 380 becomes a reality the From class can be dropped in favor
of yield-from syntax (and raise StopIteration(x) in favor of return
x). But it seems a bit of a waste to have two different trampolines,
especially since the trampoline itself is so hard to understand
(speaking for myself here :-). ISTM that the single combined
trampoline is easier to understand than the From class.

I am CC'ing Raymond so he can loop the author of Monocle (his
colleague) into this discussion -- I'd like to hear their opinion
(Monocle seems to require a decorator but it looks like it uses the
PEP 342 approach to simulate yield-from while avoiding stack buildup).

PS For Raymond and his colleague: I also still hope that Monocle will
change its mind about the proper convention for returning a value from
a coroutine -- I really think it should be raise StopIteration(value)
rather than yield value, since the latter (a) doesn't signal
sufficiently strongly (to the human reader) that the generator will
not be resumed ever again, and (b) could easily be confused with the
other uses of yield. (IOW I think yield is being overloaded too much
in Monocle.)

-- 
--Guido van Rossum (python.org/~guido)

From glyph at twistedmatrix.com  Mon Aug  2 07:18:39 2010
From: glyph at twistedmatrix.com (Glyph Lefkowitz)
Date: Mon, 2 Aug 2010 01:18:39 -0400
Subject: [Python-Dev] proto-pep: plugin proposal (for unittest)
In-Reply-To: <F7612A95-8B56-4037-85F0-799980C9DF8A@mac.com>
References: <4C5206F6.7090808@voidspace.org.uk>
	<AANLkTi=rgKJMRQ_shwAbJ3S-fKpsoxGkvUFpi2mXc-2X@mail.gmail.com>
	<AANLkTimJ7XeVMFUv_Mi1gZoayBzc23EO8snk-CbWKZ8q@mail.gmail.com>
	<4C540CFD.9030308@voidspace.org.uk>
	<4C540F95.9030606@voidspace.org.uk>
	<2E05BE10-4098-4133-AD6D-F26598519E3E@mac.com>
	<4C55914F.60705@netwok.org>
	<F7612A95-8B56-4037-85F0-799980C9DF8A@mac.com>
Message-ID: <CCA4F53B-7192-4EAB-A38D-7E55DA4D1E78@twistedmatrix.com>


On Aug 1, 2010, at 3:52 PM, Ronald Oussoren wrote:

> 
> On 1 Aug, 2010, at 17:22, ?ric Araujo wrote:
> 
>>> Speaking of which... Your documentation says it's named ~/unittest.cfg,
>>> could you make this a file in the user base (that is, the prefix where
>>> 'setup.py install --user' will install files)?
>> 
>> Putting .pydistutils.cfg .pypirc .unittest2.cfg .idlerc and possibly
>> other in the user home directory (or %APPDATA% on win32 and
>> what-have-you on Mac) is unnecessary clutter. However, $PYTHONUSERBASE
>> is not the right directory for configuration files, as pointed in
>> http://bugs.python.org/issue7175
>> 
>> It would be nice to agree on a ~/.python (resp. %APPADATA%/Python) or
>> $XDG_CONFIG_HOME/python directory and put config files there.
> 
> ~/Library/Python would be a good location on OSX, even if the 100% formally correct location would be ~/Preferences/Python (at least of framework builds, unix-style builds may want to follow the unix convention).

"100% formally" speaking, MacOS behaves like UNIX in many ways.  <http://en.wikipedia.org/wiki/Single_UNIX_Specification#Mac_OS_X_and_Mac_OS_X_Server>

It's fine to have a mac-pathname-convention-following place for such data, but please _also_ respect the UNIX-y version on the Mac.  The only possible outcome of python on the Mac respect only Mac pathnames is to have automation scripts that work fine on BSD and Linux, but then break when you try to run them on a Mac.  There is really no benefit to intentionally avoiding honoring the UNIX conventions.  (For another example, note that although Python resides in /System/Library, on the mac, the thing that's in your $PATH when you're using a terminal is the symlink in /usr/bin/python.)

Also, no, "~/Preferences" isn't the right place for it either; there's no such thing.  You probably meant "~/Library/Preferences".  I'd say that since ~/Library/Python is already used, there's no particular reason to add a new ~/Library/Preferences/Python location.  After all, if you really care a lot about platform conventions, you should put it in ~/Library/Preferences/org.python.distutils.plist, but I don't see what benefit that extra complexity would have for anyone.


From pje at telecommunity.com  Mon Aug  2 08:11:09 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Mon, 02 Aug 2010 02:11:09 -0400
Subject: [Python-Dev] Yield-From Implementation Updated for Python 3
In-Reply-To: <AANLkTikX6vHmj=wFzny-zd=dVU1Qgr3x-+8ScMak=toP@mail.gmail.c
 om>
References: <4C552850.8020406@canterbury.ac.nz>
	<AANLkTin0S5R9qAMoo4i3-E1=d1ZJ8-5=DScsee1Ljtcr@mail.gmail.com>
	<20100801181619.537B13A4175@sparrow.telecommunity.com>
	<AANLkTikX6vHmj=wFzny-zd=dVU1Qgr3x-+8ScMak=toP@mail.gmail.com>
Message-ID: <20100802061106.A64A53A4763@sparrow.telecommunity.com>

At 09:24 PM 8/1/2010 -0700, Guido van Rossum wrote:
>I don't understand all the details and corner
>cases (e.g. the concatenation of stacks

It's just to ensure that you never have From's iterating over other 
From's, vs. just iterating whatever's at the top of the stack.


>which seems to have to do with the special-casing of From objects in __new__)

It isn't connected, actually except that it's another place where I'm 
keeping From's flat, instead of nested.  (I hear that flat is better.  ;-) )


>I am curious whether, if you need a trampoline for async I/O anyway,
>there would be a swaying argument for integrating this functionality
>into the general trampoline (as in the PEP 342 example),

Originally, that was why I wasn't very enthusiastic about PEP 380; it 
didn't seem to me to be adding any new value over what you could do 
with existing, widely-used libraries.  (Twisted's had its own *and* 
multiple third-party From-ish libraries supporting it for many years now.)

After I wrote From(), however (which was originally intended to show 
why I thought 380 was unnecessary), I realized that having One 
Obvious Way to implement generator-based pseudothreads independent of 
an event loop, is actually useful precisely *because* it separates 
the pseudothreadedness from what you're using the pseudothreadedness for.

Essentially, the PEP 380-ish bit is the hardest part of writing an 
actual pseudothread implementation; connecting that implementation to 
an I/O framework is actually the relatively simple part.  You just 
write code that steps into the generator, and uses the yielded object 
to initiate an I/O operation and register a callback.  (If you're 
using Twisted or something else that has "promise"-like deferred 
results, it's *really* easy, because you only have a couple of types 
of yielded objects to deal with, and a uniform callback signature.)

Indeed, if you're using an existing async I/O framework, you don't 
even really *have* a "trampoline" as such -- you just have a bit of 
code that registers callbacks to itself, and the app's main event 
loop just calls back to that wrapper when the I/O is done.

In effect, an I/O framework integration would just give you a single 
API like, "run(From(geniter))", which then performs one iteration, 
and then registers whatever callback it's told to by the yield, and 
the callback it registers would actually be a reinvocation of run() 
on the same From instance when the I/O is ready, but with a value to 
pass back into the send(), or an error to throw().  So, the I/O 
framework's event loop is half of the "trampoline", and the wrapper 
that sends or throws, then registers an I/O callback, is the other half.

Something like:

     def run(coroutine, value=None, exc_info=()):
         if exc_info:
             action = coroutine.throw(*exc_info)
         else:
             action = coroutine.send(value)
         action.registerCallback(partial(run, coroutine))

Where 'action' is some I/O command object, and registerCallback() 
will call its argument back with a value or exc_info, after the I/O is done.

Of course, a real framework integration might actually dispatch on 
type here rather than using special command objects like this, and 
there might be more glue code to deal with exceptions, but really, 
the heart of the thing is just going to look like that.  (I just 
wrote it that way to show the basic structure.)

Really, it's just a few functions, maybe a utility routine or two, 
and maybe a big if-then or dictionary dispatch on types if you just 
want to be able to 'yield' existing I/O objects provided by the frameworks.

IOW, it's a *lot* simpler than actually rolling your own I/O or GUI 
framework like Twisted or Eventlet or wxPython or tk or some other such thing.


>But it seems a bit of a waste to have two different trampolines,
>especially since the trampoline itself is so hard to understand
>(speaking for myself here :-). ISTM that the single combined
>trampoline is easier to understand than the From class.

Well, the PEP 342 example was made to look simple, because it doesn't 
have to actually DO anything (like I/O!)  To work for real, it'd need 
some pluggability, and some things to help it interoperate with 
different GUI and I/O frameworks and event loops.  (Using your own 
event loop "for real" isn't very useful in a lot of non-trivial applications.)

Heck, after writing From(), it gave me an idea that I could just 
write a trampoline that *could* integrate with other event loops, 
with an idea to have it be a general-purpose companion to From.

But, after several wasted hours, I realized that yes, it *could* be 
written (I still have the draft), but it was mostly just something 
that would save a little boilerplate in bolting From()'s onto an 
existing async I/O framework, and not really anything to write home about.

So, I guess what I'm saying is, the benefit of separating the 
trampoline from control flow, is that people can then use them with 
their favorite event loop or framework, instead of the stdlib trying 
to compete with the experts on a slower release cycle.

There's additional benefit here in that 1) getting pseudothread 
implementations correct can be difficult, but once done, they're 
extremely stable, and 2) having a blessed syntax for identifying 
pseudothreaded calls and returns is a boon to competition in I/O frameworks.

So, instead of everybody having their own versions of From (and I've 
written more than a couple in my time), there's One Obvious Way To Do 
It.  All that will differ between I/O libraries are the actual API 
calls for I/O and scheduling and starting up pseudothreads, so there 
won't be as big of a switching barrier between frameworks.


From g.brandl at gmx.net  Mon Aug  2 08:10:58 2010
From: g.brandl at gmx.net (Georg Brandl)
Date: Mon, 02 Aug 2010 08:10:58 +0200
Subject: [Python-Dev] [RELEASED] Python 3.2 alpha 1
In-Reply-To: <AANLkTik5JUSkTem0myE-2MWJ3i_m3MFthr4sKp35kbOz@mail.gmail.com>
References: <4C55409B.5000409@python.org>
	<AANLkTik5JUSkTem0myE-2MWJ3i_m3MFthr4sKp35kbOz@mail.gmail.com>
Message-ID: <i35nm8$s4p$1@dough.gmane.org>

Thanks, Benjamin!  I'd also like to thank Martin and Ronald for the prompt
binaries, and the folks of #python-dev for support.  RMing was a pleasant
experience so far.

Georg


Am 02.08.2010 05:01, schrieb Benjamin Peterson:
> Hey, Georg! Congrats on your first release!
> 
> 2010/8/1 Georg Brandl <georg at python.org>:
> On behalf of the Python development team, I'm happy to announce the
> first alpha preview release of Python 3.2.

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.


From ronaldoussoren at mac.com  Mon Aug  2 08:18:18 2010
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Mon, 02 Aug 2010 08:18:18 +0200
Subject: [Python-Dev] proto-pep: plugin proposal (for unittest)
In-Reply-To: <CCA4F53B-7192-4EAB-A38D-7E55DA4D1E78@twistedmatrix.com>
References: <4C5206F6.7090808@voidspace.org.uk>
	<AANLkTi=rgKJMRQ_shwAbJ3S-fKpsoxGkvUFpi2mXc-2X@mail.gmail.com>
	<AANLkTimJ7XeVMFUv_Mi1gZoayBzc23EO8snk-CbWKZ8q@mail.gmail.com>
	<4C540CFD.9030308@voidspace.org.uk> <4C540F95.9030606@voidspace.org.uk>
	<2E05BE10-4098-4133-AD6D-F26598519E3E@mac.com>
	<4C55914F.60705@netwok.org>
	<F7612A95-8B56-4037-85F0-799980C9DF8A@mac.com>
	<CCA4F53B-7192-4EAB-A38D-7E55DA4D1E78@twistedmatrix.com>
Message-ID: <32658B55-9045-419E-911B-3436A2A6042D@mac.com>


On 2 Aug, 2010, at 7:18, Glyph Lefkowitz wrote:

> 
> On Aug 1, 2010, at 3:52 PM, Ronald Oussoren wrote:
> 
>> 
>> On 1 Aug, 2010, at 17:22, ?ric Araujo wrote:
>> 
>>>> Speaking of which... Your documentation says it's named ~/unittest.cfg,
>>>> could you make this a file in the user base (that is, the prefix where
>>>> 'setup.py install --user' will install files)?
>>> 
>>> Putting .pydistutils.cfg .pypirc .unittest2.cfg .idlerc and possibly
>>> other in the user home directory (or %APPDATA% on win32 and
>>> what-have-you on Mac) is unnecessary clutter. However, $PYTHONUSERBASE
>>> is not the right directory for configuration files, as pointed in
>>> http://bugs.python.org/issue7175
>>> 
>>> It would be nice to agree on a ~/.python (resp. %APPADATA%/Python) or
>>> $XDG_CONFIG_HOME/python directory and put config files there.
>> 
>> ~/Library/Python would be a good location on OSX, even if the 100% formally correct location would be ~/Preferences/Python (at least of framework builds, unix-style builds may want to follow the unix convention).
> 
> "100% formally" speaking, MacOS behaves like UNIX in many ways.  <http://en.wikipedia.org/wiki/Single_UNIX_Specification#Mac_OS_X_and_Mac_OS_X_Server>

Storing files in unix location will be confusing to many Mac users, Apple has an explicitly documented convention for where to store files and dot-files in the user's home directory aren't part of that convention.

An important reason for storing files in ~/Library/Python of ~/Library/Preferences/Python is that these locations are both logical for mac users and can be navigated to from the Finder without resorting to typing the folder name in "Go -> Go to Folder".

> 
> It's fine to have a mac-pathname-convention-following place for such data, but please _also_ respect the UNIX-y version on the Mac.  The only possible outcome of python on the Mac respect only Mac pathnames is to have automation scripts that work fine on BSD and Linux, but then break when you try to run them on a Mac.  

The stdlib should have APIs for locating common directories, although I must admit that I haven't checked if it actually does have them.  That way you can write automation scripts that work anyware, not just on systems that look a lot like Linux.   

I've written a lot of scripts that had to follow platform conventions on a lot of unix platforms, and those tended to require small changes for every new unix flavor we encountered. Non-linux platforms also have filesystem hierarchy standards, even though they are often not as detailed as the Linux ones and most unix platforms don't have a user-base that is as vocal as the linux packagers when software doesn't follow the conventions.

> There is really no benefit to intentionally avoiding honoring the UNIX conventions.  (For another example, note that although Python resides in /System/Library, on the mac, the thing that's in your $PATH when you're using a terminal is the symlink in /usr/bin/python.)
> 
> Also, no, "~/Preferences" isn't the right place for it either; there's no such thing.  You probably meant "~/Library/Preferences".  I'd say that since ~/Library/Python is already used, there's no particular reason to add a new ~/Library/Preferences/Python location.  After all, if you really care a lot about platform conventions, you should put it in ~/Library/Preferences/org.python.distutils.plist, but I don't see what benefit that extra complexity would have for anyone.

Your right, I meant ~/Library/Preferences, and I'd prefer ~/Library/Python for the reason you meant.   The actual format of the configuration files is not prescribed in any way, and I'd by -1 on storing the preferences in a plist on OSX because that is making live for programmers actively harder.


Ronald
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3567 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100802/71904676/attachment.bin>

From greg.ewing at canterbury.ac.nz  Mon Aug  2 08:28:37 2010
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Mon, 02 Aug 2010 18:28:37 +1200
Subject: [Python-Dev] proto-pep: plugin proposal (for unittest)
In-Reply-To: <CCA4F53B-7192-4EAB-A38D-7E55DA4D1E78@twistedmatrix.com>
References: <4C5206F6.7090808@voidspace.org.uk>
	<AANLkTi=rgKJMRQ_shwAbJ3S-fKpsoxGkvUFpi2mXc-2X@mail.gmail.com>
	<AANLkTimJ7XeVMFUv_Mi1gZoayBzc23EO8snk-CbWKZ8q@mail.gmail.com>
	<4C540CFD.9030308@voidspace.org.uk> <4C540F95.9030606@voidspace.org.uk>
	<2E05BE10-4098-4133-AD6D-F26598519E3E@mac.com>
	<4C55914F.60705@netwok.org>
	<F7612A95-8B56-4037-85F0-799980C9DF8A@mac.com>
	<CCA4F53B-7192-4EAB-A38D-7E55DA4D1E78@twistedmatrix.com>
Message-ID: <4C566595.8010602@canterbury.ac.nz>

Glyph Lefkowitz wrote:

> I'd say that since ~/Library/Python is already used, there's no
> particular reason to add a new ~/Library/Preferences/Python location.

I think the reason for separating out Preferences is so
that you can install a new version of a library or application
without losing the user's preferences from the previous
version.

-- 
Greg

From stephen at xemacs.org  Mon Aug  2 10:57:42 2010
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Mon, 02 Aug 2010 17:57:42 +0900
Subject: [Python-Dev] No response to posts
In-Reply-To: <i350gg$blm$1@dough.gmane.org>
References: <i32g9g$ouf$1@dough.gmane.org>
	<AANLkTi=5xfXtYbRbe8ZD5XmG7vApWZhbnm-vk3qq13Xg@mail.gmail.com>
	<i338g6$9o7$1@dough.gmane.org>
	<AANLkTin7oUUcOZFqBQnRe+0PFSPj78bEtD9p179YMe4Z@mail.gmail.com>
	<4C555E24.9040007@netwok.org> <i34v48$8lc$1@dough.gmane.org>
	<i350gg$blm$1@dough.gmane.org>
Message-ID: <878w4ptmrd.fsf@uwakimon.sk.tsukuba.ac.jp>

Ron Adam writes:

 > Something that may be more useful, is a "no activity" search field
 > with choices of day, week, month, year, etc... and make the output
 > sortable on time without activity.

That's exactly what a sort on date of activity gives you, though, and
it can be from longest down.

Also, I think that most of the "date" fields actually allow ranges
(iirc something like "today - 1 year, today" works, I've never
actually used them), but I don't think this can be easily negated in
the stock Roundup.  What could be done though is something like
"created Jan 1 1970, today - 2 years AND open" to find bugs that have
been hanging fire for more than two years.


From fuzzyman at voidspace.org.uk  Mon Aug  2 11:48:39 2010
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Mon, 02 Aug 2010 10:48:39 +0100
Subject: [Python-Dev] proto-pep: plugin proposal (for unittest)
In-Reply-To: <32658B55-9045-419E-911B-3436A2A6042D@mac.com>
References: <4C5206F6.7090808@voidspace.org.uk>	<AANLkTi=rgKJMRQ_shwAbJ3S-fKpsoxGkvUFpi2mXc-2X@mail.gmail.com>	<AANLkTimJ7XeVMFUv_Mi1gZoayBzc23EO8snk-CbWKZ8q@mail.gmail.com>	<4C540CFD.9030308@voidspace.org.uk>
	<4C540F95.9030606@voidspace.org.uk>	<2E05BE10-4098-4133-AD6D-F26598519E3E@mac.com>	<4C55914F.60705@netwok.org>	<F7612A95-8B56-4037-85F0-799980C9DF8A@mac.com>	<CCA4F53B-7192-4EAB-A38D-7E55DA4D1E78@twistedmatrix.com>
	<32658B55-9045-419E-911B-3436A2A6042D@mac.com>
Message-ID: <4C569477.4040404@voidspace.org.uk>

On 02/08/2010 07:18, Ronald Oussoren wrote:
> On 2 Aug, 2010, at 7:18, Glyph Lefkowitz wrote:
>
>    
>> On Aug 1, 2010, at 3:52 PM, Ronald Oussoren wrote:
>>
>>      
>>> On 1 Aug, 2010, at 17:22, ?ric Araujo wrote:
>>>
>>>        
>>>>> Speaking of which... Your documentation says it's named ~/unittest.cfg,
>>>>> could you make this a file in the user base (that is, the prefix where
>>>>> 'setup.py install --user' will install files)?
>>>>>            
>>>> Putting .pydistutils.cfg .pypirc .unittest2.cfg .idlerc and possibly
>>>> other in the user home directory (or %APPDATA% on win32 and
>>>> what-have-you on Mac) is unnecessary clutter. However, $PYTHONUSERBASE
>>>> is not the right directory for configuration files, as pointed in
>>>> http://bugs.python.org/issue7175
>>>>
>>>> It would be nice to agree on a ~/.python (resp. %APPADATA%/Python) or
>>>> $XDG_CONFIG_HOME/python directory and put config files there.
>>>>          
>>> ~/Library/Python would be a good location on OSX, even if the 100% formally correct location would be ~/Preferences/Python (at least of framework builds, unix-style builds may want to follow the unix convention).
>>>        
>> "100% formally" speaking, MacOS behaves like UNIX in many ways.<http://en.wikipedia.org/wiki/Single_UNIX_Specification#Mac_OS_X_and_Mac_OS_X_Server>
>>      
> Storing files in unix location will be confusing to many Mac users, Apple has an explicitly documented convention for where to store files and dot-files in the user's home directory aren't part of that convention.
>
> An important reason for storing files in ~/Library/Python of ~/Library/Preferences/Python is that these locations are both logical for mac users and can be navigated to from the Finder without resorting to typing the folder name in "Go ->  Go to Folder".
>
>    

Really? As a Mac user I have never edited (or even looked at) files in 
~/Library. I would never think of going there for finding config files 
to edit. However in my home directory I have:

     .Xauthority
     .Xcode
     . CFUserTextEncoding  - (an Apple encoding configuration for Core 
Foundation)
     .bash_profile
     .cups
     .dropbox
     .dvdcss
     .filezilla
     .fontconfig
     .hgrc
     .idlerc
     .ipython
     .mono
     .netbeans
     .parallels_settings
     .pypirc
     .wingide3

Actually that is just a small selection of the .config files/directories 
in my home directory. It is certainly *a* standard location for config 
files on the Mac, including some Apple software (XCode) and Python 
applications.

My preference would  be to follow this established and well used convention.

Michael

>> It's fine to have a mac-pathname-convention-following place for such data, but please _also_ respect the UNIX-y version on the Mac.  The only possible outcome of python on the Mac respect only Mac pathnames is to have automation scripts that work fine on BSD and Linux, but then break when you try to run them on a Mac.
>>      
> The stdlib should have APIs for locating common directories, although I must admit that I haven't checked if it actually does have them.  That way you can write automation scripts that work anyware, not just on systems that look a lot like Linux.
>
> I've written a lot of scripts that had to follow platform conventions on a lot of unix platforms, and those tended to require small changes for every new unix flavor we encountered. Non-linux platforms also have filesystem hierarchy standards, even though they are often not as detailed as the Linux ones and most unix platforms don't have a user-base that is as vocal as the linux packagers when software doesn't follow the conventions.
>
>    
>> There is really no benefit to intentionally avoiding honoring the UNIX conventions.  (For another example, note that although Python resides in /System/Library, on the mac, the thing that's in your $PATH when you're using a terminal is the symlink in /usr/bin/python.)
>>
>> Also, no, "~/Preferences" isn't the right place for it either; there's no such thing.  You probably meant "~/Library/Preferences".  I'd say that since ~/Library/Python is already used, there's no particular reason to add a new ~/Library/Preferences/Python location.  After all, if you really care a lot about platform conventions, you should put it in ~/Library/Preferences/org.python.distutils.plist, but I don't see what benefit that extra complexity would have for anyone.
>>      
> Your right, I meant ~/Library/Preferences, and I'd prefer ~/Library/Python for the reason you meant.   The actual format of the configuration files is not prescribed in any way, and I'd by -1 on storing the preferences in a plist on OSX because that is making live for programmers actively harder.
>
>
> Ronald
>    
>>      
>    
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at 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/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies ("BOGUS AGREEMENTS") that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100802/9a1bd5fd/attachment.html>

From solipsis at pitrou.net  Mon Aug  2 12:06:19 2010
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 2 Aug 2010 12:06:19 +0200
Subject: [Python-Dev] proto-pep: plugin proposal (for unittest)
References: <4C5206F6.7090808@voidspace.org.uk>
	<AANLkTi=rgKJMRQ_shwAbJ3S-fKpsoxGkvUFpi2mXc-2X@mail.gmail.com>
	<AANLkTimJ7XeVMFUv_Mi1gZoayBzc23EO8snk-CbWKZ8q@mail.gmail.com>
	<4C540CFD.9030308@voidspace.org.uk>
	<4C540F95.9030606@voidspace.org.uk>
	<2E05BE10-4098-4133-AD6D-F26598519E3E@mac.com>
	<4C55914F.60705@netwok.org>
Message-ID: <20100802120619.15ae97ab@pitrou.net>

On Sun, 01 Aug 2010 17:22:55 +0200
?ric Araujo <merwok at netwok.org> wrote:
> > Speaking of which... Your documentation says it's named ~/unittest.cfg,
> > could you make this a file in the user base (that is, the prefix where
> > 'setup.py install --user' will install files)?
> 
> Putting .pydistutils.cfg .pypirc .unittest2.cfg .idlerc and possibly
> other in the user home directory (or %APPDATA% on win32 and
> what-have-you on Mac) is unnecessary clutter. However, $PYTHONUSERBASE
> is not the right directory for configuration files, as pointed in
> http://bugs.python.org/issue7175
> 
> It would be nice to agree on a ~/.python (resp. %APPADATA%/Python) or
> $XDG_CONFIG_HOME/python directory and put config files there.

+1

Antoine.



From solipsis at pitrou.net  Mon Aug  2 12:09:31 2010
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 2 Aug 2010 12:09:31 +0200
Subject: [Python-Dev] [RELEASED] Python 3.2 alpha 1
References: <4C55409B.5000409@python.org>
	<AANLkTik5JUSkTem0myE-2MWJ3i_m3MFthr4sKp35kbOz@mail.gmail.com>
	<i35nm8$s4p$1@dough.gmane.org>
Message-ID: <20100802120931.76c3b094@pitrou.net>

On Mon, 02 Aug 2010 08:10:58 +0200
Georg Brandl <g.brandl at gmx.net> wrote:
> Thanks, Benjamin!  I'd also like to thank Martin and Ronald for the prompt
> binaries, and the folks of #python-dev for support.  RMing was a pleasant
> experience so far.

Are you already trying to lure other people into replacing you?



From ronaldoussoren at mac.com  Mon Aug  2 12:48:10 2010
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Mon, 02 Aug 2010 03:48:10 -0700 (PDT)
Subject: [Python-Dev] proto-pep: plugin proposal (for unittest)
In-Reply-To: <4C569477.4040404@voidspace.org.uk>
Message-ID: <8a1ff5c3-3538-cbde-eece-ecc098fd2927@me.com>



On 02 Aug, 2010,at 11:48 AM, Michael Foord <fuzzyman at voidspace.org.uk> wrote:

On 02/08/2010 07:18, Ronald Oussoren wrote:
On 2 Aug, 2010, at 7:18, Glyph Lefkowitz wrote:

  
On Aug 1, 2010, at 3:52 PM, Ronald Oussoren wrote:

    
On 1 Aug, 2010, at 17:22, ?ric Araujo wrote:

      
Speaking of which... Your documentation says it's named ~/unittest.cfg,
could you make this a file in the user base (that is, the prefix where
'setup.py install --user' will install files)?
          
Putting .pydistutils.cfg .pypirc .unittest2.cfg .idlerc and possibly
other in the user home directory (or %APPDATA% on win32 and
what-have-you on Mac) is unnecessary clutter. However, $PYTHONUSERBASE
is not the right directory for configuration files, as pointed in
http://bugs.python.org/issue7175

It would be nice to agree on a ~/.python (resp. %APPADATA%/Python) or
$XDG_CONFIG_HOME/python directory and put config files there.
        
~/Library/Python would be a good location on OSX, even if the 100% formally correct location would be ~/Preferences/Python (at least of framework builds, unix-style builds may want to follow the unix convention).
      
"100% formally" speaking, MacOS behaves like UNIX in many ways.  <http://en.wikipedia.org/wiki/Single_UNIX_Specification#Mac_OS_X_and_Mac_OS_X_Server>
    
Storing files in unix location will be confusing to many Mac users, Apple has an explicitly documented convention for where to store files and dot-files in the user's home directory aren't part of that convention.

An important reason for storing files in ~/Library/Python of ~/Library/Preferences/Python is that these locations are both logical for mac users and can be navigated to from the Finder without resorting to typing the folder name in "Go -> Go to Folder".

  

Really? As a Mac user I have never edited (or even looked at) files in ~/Library. I would never think of going there for finding config files to edit. However in my home directory I have:

??? .Xauthority
??? .Xcode
??? . CFUserTextEncoding? - (an Apple encoding configuration for Core Foundation)
??? .bash_profile
??? .cups
??? .dropbox
??? .dvdcss
??? .filezilla
??? .fontconfig
??? .hgrc
??? .idlerc
??? .ipython
??? .mono
??? .netbeans
??? .parallels_settings
??? .pypirc
??? .wingide3

Actually that is just a small selection of the .config files/directories in my home directory. It is certainly *a* standard location for config files on the Mac, including some Apple software (XCode) and Python applications.
?
The only apple one that is actually used is the .CFUserTextEncoding file, I have an .Xcode in my home as well but that is empty and last updated in 2007. ?AFAIK current versions of Xcode store preferences in ~/Library/Preferences. ?Most of the other ones are ports of unix tools and store junk in the standard unix location for storing configuration. ? Try edit one without resorting to the command-line, with a default configuration of the Finder you cannot even see these files (and that includes the File open dialog of tools like Text Edit).

The reason you don't normally look in ~/Library/Preferences is that GUI tools on OSX have configuration screens for editing preferences and you don't have to edit them manually. ?



My preference would? be to follow this established and well used convention.
?
My preference is still to use ~/Library/Python (or a subdirectory thereof) and filenames that don't start with a dot.

Ronald
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100802/12f8284a/attachment.html>

From fuzzyman at voidspace.org.uk  Mon Aug  2 12:53:27 2010
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Mon, 02 Aug 2010 11:53:27 +0100
Subject: [Python-Dev] proto-pep: plugin proposal (for unittest)
In-Reply-To: <8a1ff5c3-3538-cbde-eece-ecc098fd2927@me.com>
References: <8a1ff5c3-3538-cbde-eece-ecc098fd2927@me.com>
Message-ID: <4C56A3A7.3010006@voidspace.org.uk>

On 02/08/2010 11:48, Ronald Oussoren wrote:
>
>
> On 02 Aug, 2010,at 11:48 AM, Michael Foord <fuzzyman at voidspace.org.uk> 
> wrote:
>
>> On 02/08/2010 07:18, Ronald Oussoren wrote:
>>> On 2 Aug, 2010, at 7:18, Glyph Lefkowitz wrote:
>>>
>>>    
>>>> On Aug 1, 2010, at 3:52 PM, Ronald Oussoren wrote:
>>>>
>>>>      
>>>>> On 1 Aug, 2010, at 17:22, ?ric Araujo wrote:
>>>>>
>>>>>        
>>>>>>> Speaking of which... Your documentation says it's named ~/unittest.cfg,
>>>>>>> could you make this a file in the user base (that is, the prefix where
>>>>>>> 'setup.py install --user' will install files)?
>>>>>>>            
>>>>>> Putting .pydistutils.cfg .pypirc .unittest2.cfg .idlerc and possibly
>>>>>> other in the user home directory (or %APPDATA% on win32 and
>>>>>> what-have-you on Mac) is unnecessary clutter. However, $PYTHONUSERBASE
>>>>>> is not the right directory for configuration files, as pointed in
>>>>>> http://bugs.python.org/issue7175
>>>>>>
>>>>>> It would be nice to agree on a ~/.python (resp. %APPADATA%/Python) or
>>>>>> $XDG_CONFIG_HOME/python directory and put config files there.
>>>>>>          
>>>>> ~/Library/Python would be a good location on OSX, even if the 100% formally correct location would be ~/Preferences/Python (at least of framework builds, unix-style builds may want to follow the unix convention).
>>>>>        
>>>> "100% formally" speaking, MacOS behaves like UNIX in many ways.<http://en.wikipedia.org/wiki/Single_UNIX_Specification#Mac_OS_X_and_Mac_OS_X_Server>
>>>>      
>>> Storing files in unix location will be confusing to many Mac users, Apple has an explicitly documented convention for where to store files and dot-files in the user's home directory aren't part of that convention.
>>>
>>> An important reason for storing files in ~/Library/Python of ~/Library/Preferences/Python is that these locations are both logical for mac users and can be navigated to from the Finder without resorting to typing the folder name in "Go ->  Go to Folder".
>>>
>>>    
>>
>> Really? As a Mac user I have never edited (or even looked at) files 
>> in ~/Library. I would never think of going there for finding config 
>> files to edit. However in my home directory I have:
>>
>> .Xauthority
>> .Xcode
>> . CFUserTextEncoding - (an Apple encoding configuration for Core 
>> Foundation)
>> .bash_profile
>> .cups
>> .dropbox
>> .dvdcss
>> .filezilla
>> .fontconfig
>> .hgrc
>> .idlerc
>> .ipython
>> .mono
>> .netbeans
>> .parallels_settings
>> .pypirc
>> .wingide3
>>
>> Actually that is just a small selection of the .config 
>> files/directories in my home directory. It is certainly *a* standard 
>> location for config files on the Mac, including some Apple software 
>> (XCode) and Python applications.
> The only apple one that is actually used is the .CFUserTextEncoding 
> file, I have an .Xcode in my home as well but that is empty and last 
> updated in 2007. AFAIK current versions of Xcode store preferences in 
> ~/Library/Preferences. Most of the other ones are ports of unix tools 
> and store junk in the standard unix location for storing 
> configuration. Try edit one without resorting to the command-line, 
> with a default configuration of the Finder you cannot even see these 
> files (and that includes the File open dialog of tools like Text Edit)
>
> The reason you don't normally look in ~/Library/Preferences is that 
> GUI tools on OSX have configuration screens for editing preferences 
> and you don't have to edit them manually.

Right, so what you are saying is that for user editable text config 
files ~/Library/Preferences is *not* a convention - and in fact the unix 
convention of dot files in the home directory is commonly used on the 
Mac. :-)

Michael

>
>>
>>
>> My preference would be to follow this established and well used 
>> convention.
> My preference is still to use ~/Library/Python (or a subdirectory 
> thereof) and filenames that don't start with a dot.
>
> Ronald


-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (?BOGUS AGREEMENTS?) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.



From fuzzyman at voidspace.org.uk  Mon Aug  2 13:00:09 2010
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Mon, 02 Aug 2010 12:00:09 +0100
Subject: [Python-Dev] proto-pep: plugin proposal (for unittest)
In-Reply-To: <8a1ff5c3-3538-cbde-eece-ecc098fd2927@me.com>
References: <8a1ff5c3-3538-cbde-eece-ecc098fd2927@me.com>
Message-ID: <4C56A539.8000709@voidspace.org.uk>

On 02/08/2010 11:48, Ronald Oussoren wrote:
>
>
> On 02 Aug, 2010,at 11:48 AM, Michael Foord <fuzzyman at voidspace.org.uk> 
> wrote:
>
>> On 02/08/2010 07:18, Ronald Oussoren wrote:
>>> On 2 Aug, 2010, at 7:18, Glyph Lefkowitz wrote:
>>>
>>>    
>>>> On Aug 1, 2010, at 3:52 PM, Ronald Oussoren wrote:
>>>>
>>>>      
>>>>> On 1 Aug, 2010, at 17:22, ?ric Araujo wrote:
>>>>>
>>>>>        
>>>>>>> Speaking of which... Your documentation says it's named ~/unittest.cfg,
>>>>>>> could you make this a file in the user base (that is, the prefix where
>>>>>>> 'setup.py install --user' will install files)?
>>>>>>>            
>>>>>> Putting .pydistutils.cfg .pypirc .unittest2.cfg .idlerc and possibly
>>>>>> other in the user home directory (or %APPDATA% on win32 and
>>>>>> what-have-you on Mac) is unnecessary clutter. However, $PYTHONUSERBASE
>>>>>> is not the right directory for configuration files, as pointed in
>>>>>> http://bugs.python.org/issue7175
>>>>>>
>>>>>> It would be nice to agree on a ~/.python (resp. %APPADATA%/Python) or
>>>>>> $XDG_CONFIG_HOME/python directory and put config files there.
>>>>>>          
>>>>> ~/Library/Python would be a good location on OSX, even if the 100% formally correct location would be ~/Preferences/Python (at least of framework builds, unix-style builds may want to follow the unix convention).
>>>>>        
>>>> "100% formally" speaking, MacOS behaves like UNIX in many ways.<http://en.wikipedia.org/wiki/Single_UNIX_Specification#Mac_OS_X_and_Mac_OS_X_Server>
>>>>      
>>> Storing files in unix location will be confusing to many Mac users, Apple has an explicitly documented convention for where to store files and dot-files in the user's home directory aren't part of that convention.
>>>
>>> An important reason for storing files in ~/Library/Python of ~/Library/Preferences/Python is that these locations are both logical for mac users and can be navigated to from the Finder without resorting to typing the folder name in "Go ->  Go to Folder".
>>>
>>>    
>>
>> Really? As a Mac user I have never edited (or even looked at) files 
>> in ~/Library. I would never think of going there for finding config 
>> files to edit. However in my home directory I have:
>>
>> .Xauthority
>> .Xcode
>> . CFUserTextEncoding - (an Apple encoding configuration for Core 
>> Foundation)
>> .bash_profile
>> .cups
>> .dropbox
>> .dvdcss
>> .filezilla
>> .fontconfig
>> .hgrc
>> .idlerc
>> .ipython
>> .mono
>> .netbeans
>> .parallels_settings
>> .pypirc
>> .wingide3
>>
>> Actually that is just a small selection of the .config 
>> files/directories in my home directory. It is certainly *a* standard 
>> location for config files on the Mac, including some Apple software 
>> (XCode) and Python applications.
> The only apple one that is actually used is the .CFUserTextEncoding 
> file, I have an .Xcode in my home as well but that is empty and last 
> updated in 2007. AFAIK current versions of Xcode store preferences in 
> ~/Library/Preferences. Most of the other ones are ports of unix tools 
> and store junk in the standard unix location for storing 
> configuration. Try edit one without resorting to the command-line

The configuration files we are discussing are for command line tools - 
so I don't think that having to resort to the command line is a 
disadvantage at all. If users don't / can't use the command line then 
they *won't* want to edit these files anyway.

If they are used to the command line then ~/.python32/distutils.cfg is 
going to be a very natural place for them.

If we provide GUI tools that use these config files then we will also 
provide GUI tools that use these config files then we will also provide 
GUI tools to configure them - so I can't see a downside to having them 
in the unix location and no upside to putting them elsewhere.

Michael

> , with a default configuration of the Finder you cannot even see these 
> files (and that includes the File open dialog of tools like Text Edit)
>
> The reason you don't normally look in ~/Library/Preferences is that 
> GUI tools on OSX have configuration screens for editing preferences 
> and you don't have to edit them manually.
>
>>
>>
>> My preference would be to follow this established and well used 
>> convention.
> My preference is still to use ~/Library/Python (or a subdirectory 
> thereof) and filenames that don't start with a dot.
>
> Ronald


-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (?BOGUS AGREEMENTS?) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.



From ziade.tarek at gmail.com  Mon Aug  2 13:05:33 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 2 Aug 2010 13:05:33 +0200
Subject: [Python-Dev] PEP 376 proposed changes for basic plugins support
In-Reply-To: <AANLkTinyjMkF2n91zS+48n6B_gkp9szW_bH0XJgTDh7D@mail.gmail.com>
References: <AANLkTinyjMkF2n91zS+48n6B_gkp9szW_bH0XJgTDh7D@mail.gmail.com>
Message-ID: <AANLkTimUaVaVbAcM+W-A7oMUsAaPhm+Bat-UY9L37R=m@mail.gmail.com>

On Sun, Aug 1, 2010 at 10:37 PM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
> Hello,
>
> Here's a proposal to extend PEP 376 to support a basic plugins feature
> -- you should read PEP 376 before reading this mail
>
> It's basically Phillip's entry points, but with an activation flag,
> and a per-user config file.
>
> = adding a PLUGINS file =
>
> A new file called 'PLUGINS' is added to the dist-info directory at
> install time, and contains a list of plugins for the installed
> distribution.

After some more thoughts, ISTM that it would be better to have the
plugin definitions in a new metadata field in PEP 345,
rather than in the PLUGINS file. The reason is that it will allow
tools and users to browse PyPI to look for plugins.

The PLUGINS file can be kept only for the state value, which is not read-only.

Regards,
Tarek

-- 
Tarek Ziad? | http://ziade.org

From ziade.tarek at gmail.com  Mon Aug  2 13:10:47 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 2 Aug 2010 13:10:47 +0200
Subject: [Python-Dev] PEP 376 proposed changes for basic plugins support
In-Reply-To: <20100802010616.5FD133A4758@sparrow.telecommunity.com>
References: <AANLkTinyjMkF2n91zS+48n6B_gkp9szW_bH0XJgTDh7D@mail.gmail.com>
	<4C55FF0F.3010702@voidspace.org.uk>
	<AANLkTim1af-zWEYF4U-vTr6d+8HkqFCycMVmQYsqpDcN@mail.gmail.com>
	<4C5609A3.3090008@voidspace.org.uk>
	<AANLkTimU-OUh8fzFoRvHMsQOqVa+jsFTfPyZKeY=heVg@mail.gmail.com>
	<20100802010616.5FD133A4758@sparrow.telecommunity.com>
Message-ID: <AANLkTi=UDktBHXeQTU6_ouPk2sfnmhztMLY9yjzZJHP7@mail.gmail.com>

On Mon, Aug 2, 2010 at 3:06 AM, P.J. Eby <pje at telecommunity.com> wrote:
..
>
> So without specific examples of why this is a problem, it's hard to see why
> a special Python-specific set of configuration files is needed to resolve
> it, vs. say, encouraging application authors to use the available
> alternatives for doing plugin directories, config files, etc.

I don't have a specific example in mind, and I must admit that if an
application does the right thing
(provide the right configuration file), this activate feature is not
useful at all. So it seems to be a bad idea.

I propose that we drop the PLUGINS file idea and we add a new metadata
field called Provides-Plugin
in PEP 345, which will contain the info I've described minus the state
field. This will allow us to expose
plugins at PyPI.

IOW, have entry points like setuptools provides, but in a metadata
field instead of a entry_points.txt file.

Tarek

-- 
Tarek Ziad? | http://ziade.org

From merwok at netwok.org  Mon Aug  2 14:04:01 2010
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Mon, 02 Aug 2010 14:04:01 +0200
Subject: [Python-Dev] PEP 376 proposed changes for basic plugins support
In-Reply-To: <AANLkTimUaVaVbAcM+W-A7oMUsAaPhm+Bat-UY9L37R=m@mail.gmail.com>
References: <AANLkTinyjMkF2n91zS+48n6B_gkp9szW_bH0XJgTDh7D@mail.gmail.com>
	<AANLkTimUaVaVbAcM+W-A7oMUsAaPhm+Bat-UY9L37R=m@mail.gmail.com>
Message-ID: <4C56B431.2020304@netwok.org>

> The PLUGINS file can be kept only for the state value, which is not read-only.

It will be for OS packages.

Regards


From ncoghlan at gmail.com  Mon Aug  2 14:08:23 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 2 Aug 2010 22:08:23 +1000
Subject: [Python-Dev] pdb mini-sprint report and questions
In-Reply-To: <AANLkTikSXtXc=0Xz8e6SL6HXReLUJOAkCtFdnr2DbusV@mail.gmail.com>
References: <i2vkq0$llq$1@dough.gmane.org>
	<AANLkTikSXtXc=0Xz8e6SL6HXReLUJOAkCtFdnr2DbusV@mail.gmail.com>
Message-ID: <AANLkTikGscfJaGkPEP4WZ9rOLX5GX4XBthTzwDd4NtOg@mail.gmail.com>

On Mon, Aug 2, 2010 at 10:10 AM, Ilya Sandler <ilya.sandler at gmail.com> wrote:
> Hello,
>
> I'm the submitter of the original patch and would like to help with it if I can.
>
>> One issue that's not yet closed is #7245, which adds a (very nice IMO)
>> feature: when you press Ctrl-C while the program being debugged runs,
>> you will not get a traceback but execution is suspended, and you can
>> debug from the current point of execution -- just like in gdb.
>>
>> However, there were apparently issues with some of the buildbots when
>> the patch was applied for a short time. ?I also don't know how and if
>> it works on Windows, so I'd need some helpful people testing it.
>
> For whatever it's worth, it worked for me with python trunk (2.x) on
> Vista, when I tried it manually. ?But I don't know how to implement
> the unit test there (subprocess module doesn't support sending SIGINT
> programmatically on windows either). So the test_pdb2 test does not
> check signal behavior on Windows platforms.

I haven't looked at the relevant patch to check if this is applicable
to the test case, but actually sending a Ctrl-C character to stdin
(via a pipe) can work (although I think there can be some weirdness if
the parent process has no console).

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From mal at egenix.com  Mon Aug  2 14:21:26 2010
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon, 02 Aug 2010 14:21:26 +0200
Subject: [Python-Dev] PEP 376 proposed changes for basic plugins support
In-Reply-To: <AANLkTi=UDktBHXeQTU6_ouPk2sfnmhztMLY9yjzZJHP7@mail.gmail.com>
References: <AANLkTinyjMkF2n91zS+48n6B_gkp9szW_bH0XJgTDh7D@mail.gmail.com>	<4C55FF0F.3010702@voidspace.org.uk>	<AANLkTim1af-zWEYF4U-vTr6d+8HkqFCycMVmQYsqpDcN@mail.gmail.com>	<4C5609A3.3090008@voidspace.org.uk>	<AANLkTimU-OUh8fzFoRvHMsQOqVa+jsFTfPyZKeY=heVg@mail.gmail.com>	<20100802010616.5FD133A4758@sparrow.telecommunity.com>
	<AANLkTi=UDktBHXeQTU6_ouPk2sfnmhztMLY9yjzZJHP7@mail.gmail.com>
Message-ID: <4C56B846.9090009@egenix.com>

Tarek Ziad? wrote:
> On Mon, Aug 2, 2010 at 3:06 AM, P.J. Eby <pje at telecommunity.com> wrote:
> ..
>>
>> So without specific examples of why this is a problem, it's hard to see why
>> a special Python-specific set of configuration files is needed to resolve
>> it, vs. say, encouraging application authors to use the available
>> alternatives for doing plugin directories, config files, etc.
> 
> I don't have a specific example in mind, and I must admit that if an
> application does the right thing
> (provide the right configuration file), this activate feature is not
> useful at all. So it seems to be a bad idea.
> 
> I propose that we drop the PLUGINS file idea and we add a new metadata
> field called Provides-Plugin
> in PEP 345, which will contain the info I've described minus the state
> field. This will allow us to expose
> plugins at PyPI.
> 
> IOW, have entry points like setuptools provides, but in a metadata
> field instead of a entry_points.txt file.

Do we really need to make Python packaging even more complicated by
adding support for application-specific plugin mechanisms ?

Packages can already work as application plugins by simply defining
a plugins namespace package and then placing the plugin packages
into that namespace.

See Zope for an example of how well this simply mechanism works out in
practice: it simply scans the "Products" namespace for sub-packages and
then loads each sub-package it finds to have it register itself with Zope.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Aug 02 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/
________________________________________________________________________

::: 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/

From exarkun at twistedmatrix.com  Mon Aug  2 14:31:45 2010
From: exarkun at twistedmatrix.com (exarkun at twistedmatrix.com)
Date: Mon, 02 Aug 2010 12:31:45 -0000
Subject: [Python-Dev] PEP 376 proposed changes for basic plugins support
In-Reply-To: <4C56B846.9090009@egenix.com>
References: <AANLkTinyjMkF2n91zS+48n6B_gkp9szW_bH0XJgTDh7D@mail.gmail.com>
	<4C55FF0F.3010702@voidspace.org.uk>
	<AANLkTim1af-zWEYF4U-vTr6d+8HkqFCycMVmQYsqpDcN@mail.gmail.com>
	<4C5609A3.3090008@voidspace.org.uk>
	<AANLkTimU-OUh8fzFoRvHMsQOqVa+jsFTfPyZKeY=heVg@mail.gmail.com>
	<20100802010616.5FD133A4758@sparrow.telecommunity.com>
	<AANLkTi=UDktBHXeQTU6_ouPk2sfnmhztMLY9yjzZJHP7@mail.gmail.com>
	<4C56B846.9090009@egenix.com>
Message-ID: <20100802123145.2305.1286368223.divmod.xquotient.3@localhost.localdomain>

On 12:21 pm, mal at egenix.com wrote:
>Tarek Ziad? wrote:
>>On Mon, Aug 2, 2010 at 3:06 AM, P.J. Eby <pje at telecommunity.com> 
>>wrote:
>>..
>>>
>>>So without specific examples of why this is a problem, it's hard to 
>>>see why
>>>a special Python-specific set of configuration files is needed to 
>>>resolve
>>>it, vs. say, encouraging application authors to use the available
>>>alternatives for doing plugin directories, config files, etc.
>>
>>I don't have a specific example in mind, and I must admit that if an
>>application does the right thing
>>(provide the right configuration file), this activate feature is not
>>useful at all. So it seems to be a bad idea.
>>
>>I propose that we drop the PLUGINS file idea and we add a new metadata
>>field called Provides-Plugin
>>in PEP 345, which will contain the info I've described minus the state
>>field. This will allow us to expose
>>plugins at PyPI.
>>
>>IOW, have entry points like setuptools provides, but in a metadata
>>field instead of a entry_points.txt file.
>
>Do we really need to make Python packaging even more complicated by
>adding support for application-specific plugin mechanisms ?
>
>Packages can already work as application plugins by simply defining
>a plugins namespace package and then placing the plugin packages
>into that namespace.
>
>See Zope for an example of how well this simply mechanism works out in
>practice: it simply scans the "Products" namespace for sub-packages and
>then loads each sub-package it finds to have it register itself with 
>Zope.

This is also roughly how Twisted's plugin system works.  One drawback, 
though, is that it means potentially executing a large amount of Python 
in order to load plugins.  This can build up to a significant 
performance issue as more and more plugins are installed.

Jean-Paul

From fuzzyman at voidspace.org.uk  Mon Aug  2 15:17:48 2010
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Mon, 02 Aug 2010 14:17:48 +0100
Subject: [Python-Dev] PEP 376 proposed changes for basic plugins support
In-Reply-To: <20100802123145.2305.1286368223.divmod.xquotient.3@localhost.localdomain>
References: <AANLkTinyjMkF2n91zS+48n6B_gkp9szW_bH0XJgTDh7D@mail.gmail.com>	<4C55FF0F.3010702@voidspace.org.uk>	<AANLkTim1af-zWEYF4U-vTr6d+8HkqFCycMVmQYsqpDcN@mail.gmail.com>	<4C5609A3.3090008@voidspace.org.uk>	<AANLkTimU-OUh8fzFoRvHMsQOqVa+jsFTfPyZKeY=heVg@mail.gmail.com>	<20100802010616.5FD133A4758@sparrow.telecommunity.com>	<AANLkTi=UDktBHXeQTU6_ouPk2sfnmhztMLY9yjzZJHP7@mail.gmail.com>	<4C56B846.9090009@egenix.com>
	<20100802123145.2305.1286368223.divmod.xquotient.3@localhost.localdomain>
Message-ID: <4C56C57C.4000800@voidspace.org.uk>

On 02/08/2010 13:31, exarkun at twistedmatrix.com wrote:
> On 12:21 pm, mal at egenix.com wrote:
>> Tarek Ziad? wrote:
>>> On Mon, Aug 2, 2010 at 3:06 AM, P.J. Eby <pje at telecommunity.com> wrote:
>>> ..
>>>>
>>>> So without specific examples of why this is a problem, it's hard to 
>>>> see why
>>>> a special Python-specific set of configuration files is needed to 
>>>> resolve
>>>> it, vs. say, encouraging application authors to use the available
>>>> alternatives for doing plugin directories, config files, etc.
>>>
>>> I don't have a specific example in mind, and I must admit that if an
>>> application does the right thing
>>> (provide the right configuration file), this activate feature is not
>>> useful at all. So it seems to be a bad idea.
>>>
>>> I propose that we drop the PLUGINS file idea and we add a new metadata
>>> field called Provides-Plugin
>>> in PEP 345, which will contain the info I've described minus the state
>>> field. This will allow us to expose
>>> plugins at PyPI.
>>>
>>> IOW, have entry points like setuptools provides, but in a metadata
>>> field instead of a entry_points.txt file.
>>
>> Do we really need to make Python packaging even more complicated by
>> adding support for application-specific plugin mechanisms ?
>>
>> Packages can already work as application plugins by simply defining
>> a plugins namespace package and then placing the plugin packages
>> into that namespace.
>>
>> See Zope for an example of how well this simply mechanism works out in
>> practice: it simply scans the "Products" namespace for sub-packages and
>> then loads each sub-package it finds to have it register itself with 
>> Zope.
>
> This is also roughly how Twisted's plugin system works.  One drawback, 
> though, is that it means potentially executing a large amount of 
> Python in order to load plugins.  This can build up to a significant 
> performance issue as more and more plugins are installed.
>

unittest will solve this problem by having plugins explicitly enabled in 
its own configuration system, and possibly managed through a separate 
tool like a plugins subcommand. The full package list will *only* need 
to be scanned when managing plugins, not during normal execution.

Having this distutils2 supported "plugin declaration and discovery" will 
be extremely useful for the unittest plugin system. Given that plugins 
may need configuring after installation, and tools that handle both 
activation and configuration can be provided, it doesn't seem a heavy cost.

The downside to this is that installing and activating plugins are two 
separate steps. Given that each project can have a different set of 
plugins enabled I don't see a way round it.

Michael

> Jean-Paul
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at 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/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (?BOGUS AGREEMENTS?) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100802/a5e244fd/attachment.html>

From mal at egenix.com  Mon Aug  2 15:27:45 2010
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon, 02 Aug 2010 15:27:45 +0200
Subject: [Python-Dev] PEP 376 proposed changes for basic plugins support
In-Reply-To: <20100802123145.2305.1286368223.divmod.xquotient.3@localhost.localdomain>
References: <AANLkTinyjMkF2n91zS+48n6B_gkp9szW_bH0XJgTDh7D@mail.gmail.com>	<4C55FF0F.3010702@voidspace.org.uk>	<AANLkTim1af-zWEYF4U-vTr6d+8HkqFCycMVmQYsqpDcN@mail.gmail.com>	<4C5609A3.3090008@voidspace.org.uk>	<AANLkTimU-OUh8fzFoRvHMsQOqVa+jsFTfPyZKeY=heVg@mail.gmail.com>	<20100802010616.5FD133A4758@sparrow.telecommunity.com>	<AANLkTi=UDktBHXeQTU6_ouPk2sfnmhztMLY9yjzZJHP7@mail.gmail.com>	<4C56B846.9090009@egenix.com>
	<20100802123145.2305.1286368223.divmod.xquotient.3@localhost.localdomain>
Message-ID: <4C56C7D1.7070003@egenix.com>

exarkun at twistedmatrix.com wrote:
> On 12:21 pm, mal at egenix.com wrote:
>> Tarek Ziad? wrote:
>>> On Mon, Aug 2, 2010 at 3:06 AM, P.J. Eby <pje at telecommunity.com> wrote:
>>> ..
>>>>
>>>> So without specific examples of why this is a problem, it's hard to
>>>> see why
>>>> a special Python-specific set of configuration files is needed to
>>>> resolve
>>>> it, vs. say, encouraging application authors to use the available
>>>> alternatives for doing plugin directories, config files, etc.
>>>
>>> I don't have a specific example in mind, and I must admit that if an
>>> application does the right thing
>>> (provide the right configuration file), this activate feature is not
>>> useful at all. So it seems to be a bad idea.
>>>
>>> I propose that we drop the PLUGINS file idea and we add a new metadata
>>> field called Provides-Plugin
>>> in PEP 345, which will contain the info I've described minus the state
>>> field. This will allow us to expose
>>> plugins at PyPI.
>>>
>>> IOW, have entry points like setuptools provides, but in a metadata
>>> field instead of a entry_points.txt file.
>>
>> Do we really need to make Python packaging even more complicated by
>> adding support for application-specific plugin mechanisms ?
>>
>> Packages can already work as application plugins by simply defining
>> a plugins namespace package and then placing the plugin packages
>> into that namespace.
>>
>> See Zope for an example of how well this simply mechanism works out in
>> practice: it simply scans the "Products" namespace for sub-packages and
>> then loads each sub-package it finds to have it register itself with
>> Zope.
> 
> This is also roughly how Twisted's plugin system works.  One drawback,
> though, is that it means potentially executing a large amount of Python
> in order to load plugins.  This can build up to a significant
> performance issue as more and more plugins are installed.

I'd say that it's up to the application to deal with this problem.

An application which requires lots and lots of plugins could
define a registration protocol that does not require loading
all plugins at scanning time.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Aug 02 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/
________________________________________________________________________

::: 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/

From ronaldoussoren at mac.com  Mon Aug  2 15:34:36 2010
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Mon, 02 Aug 2010 06:34:36 -0700 (PDT)
Subject: [Python-Dev] proto-pep: plugin proposal (for unittest)
In-Reply-To: <4C56A539.8000709@voidspace.org.uk>
Message-ID: <f9203038-f94b-eb28-b9af-d3200dc27db9@me.com>



On 02 Aug, 2010,at 01:00 PM, Michael Foord <fuzzyman at voidspace.org.uk> wrote:

> The only apple one that is actually used is the .CFUserTextEncoding 
> file, I have an .Xcode in my home as well but that is empty and last 
> updated in 2007. AFAIK current versions of Xcode store preferences in 
> ~/Library/Preferences. Most of the other ones are ports of unix tools 
> and store junk in the standard unix location for storing 
> configuration. Try edit one without resorting to the command-line

The configuration files we are discussing are for command line tools - 
so I don't think that having to resort to the command line is a 
disadvantage at all. If users don't / can't use the command line then 
they *won't* want to edit these files anyway.
?
Not being comfortable at the command-line is not the same as not wanting to edit the global configuration of unittest or distutils.

Anyway, does that mean that the configuration should move if I create a patch for IDLE that allows you the manage the unittest configuration through a GUI?


If they are used to the command line then ~/.python32/distutils.cfg is 
going to be a very natural place for them.
?
That location isn't natural for me. If we invent a new location for python-related configuration file we might as well do it properly and follow platform conventions.

The MacOSX conventions are described here <http://developer.apple.com/mac/library/documentation/MacOSX/Conceptual/BPFileSystem/BPFileSystem.html#//apple_ref/doc/uid/10000185-SW1>.

Macosx-is-not-a-crappy-linux-ly yours,

??Ronald
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100802/36396a3d/attachment.html>

From fuzzyman at voidspace.org.uk  Mon Aug  2 15:43:10 2010
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Mon, 02 Aug 2010 14:43:10 +0100
Subject: [Python-Dev] proto-pep: plugin proposal (for unittest)
In-Reply-To: <f9203038-f94b-eb28-b9af-d3200dc27db9@me.com>
References: <f9203038-f94b-eb28-b9af-d3200dc27db9@me.com>
Message-ID: <4C56CB6E.10901@voidspace.org.uk>

On 02/08/2010 14:34, Ronald Oussoren wrote:
>
>
> On 02 Aug, 2010,at 01:00 PM, Michael Foord <fuzzyman at voidspace.org.uk> 
> wrote:
>
>> > The only apple one that is actually used is the .CFUserTextEncoding
>> > file, I have an .Xcode in my home as well but that is empty and last
>> > updated in 2007. AFAIK current versions of Xcode store preferences in
>> > ~/Library/Preferences. Most of the other ones are ports of unix tools
>> > and store junk in the standard unix location for storing
>> > configuration. Try edit one without resorting to the command-line
>>
>> The configuration files we are discussing are for command line tools -
>> so I don't think that having to resort to the command line is a
>> disadvantage at all. If users don't / can't use the command line then
>> they *won't* want to edit these files anyway.
> Not being comfortable at the command-line is not the same as not 
> wanting to edit the global configuration of unittest or distutils.
>
> Anyway, does that mean that the configuration should move if I create 
> a patch for IDLE that allows you the manage the unittest configuration 
> through a GUI?
>
Nope, as I doubt for *most* users it will be the primary way of editing 
the file.

>>
>> If they are used to the command line then ~/.python32/distutils.cfg is
>> going to be a very natural place for them.
> That location isn't natural for me. If we invent a new location for 
> python-related configuration file we might as well do it properly and 
> follow platform conventions.
>

But you yourself said that it *isn't* normal to have files we expect the 
user to edit in the location you suggested - and a glance on my system 
is that use ~/.app files is a *very* common convention on the Mac.


Michael
> The MacOSX conventions are described here 
> <http://developer.apple.com/mac/library/documentation/MacOSX/Conceptual/BPFileSystem/BPFileSystem.html#//apple_ref/doc/uid/10000185-SW1>.
>
> Macosx-is-not-a-crappy-linux-ly yours,
>
>   Ronald


-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies ("BOGUS AGREEMENTS") that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100802/f601b567/attachment.html>

From exarkun at twistedmatrix.com  Mon Aug  2 15:53:54 2010
From: exarkun at twistedmatrix.com (exarkun at twistedmatrix.com)
Date: Mon, 02 Aug 2010 13:53:54 -0000
Subject: [Python-Dev] PEP 376 proposed changes for basic plugins support
In-Reply-To: <4C56C7D1.7070003@egenix.com>
References: <AANLkTinyjMkF2n91zS+48n6B_gkp9szW_bH0XJgTDh7D@mail.gmail.com>
	<4C55FF0F.3010702@voidspace.org.uk>
	<AANLkTim1af-zWEYF4U-vTr6d+8HkqFCycMVmQYsqpDcN@mail.gmail.com>
	<4C5609A3.3090008@voidspace.org.uk>
	<AANLkTimU-OUh8fzFoRvHMsQOqVa+jsFTfPyZKeY=heVg@mail.gmail.com>
	<20100802010616.5FD133A4758@sparrow.telecommunity.com>
	<AANLkTi=UDktBHXeQTU6_ouPk2sfnmhztMLY9yjzZJHP7@mail.gmail.com>
	<4C56B846.9090009@egenix.com>
	<20100802123145.2305.1286368223.divmod.xquotient.3@localhost.localdomain>
	<4C56C7D1.7070003@egenix.com>
Message-ID: <20100802135354.2305.1593696105.divmod.xquotient.73@localhost.localdomain>

On 01:27 pm, mal at egenix.com wrote:
>exarkun at twistedmatrix.com wrote:
>>On 12:21 pm, mal at egenix.com wrote:
>>>
>>>See Zope for an example of how well this simply mechanism works out 
>>>in
>>>practice: it simply scans the "Products" namespace for sub-packages 
>>>and
>>>then loads each sub-package it finds to have it register itself with
>>>Zope.
>>
>>This is also roughly how Twisted's plugin system works.  One drawback,
>>though, is that it means potentially executing a large amount of 
>>Python
>>in order to load plugins.  This can build up to a significant
>>performance issue as more and more plugins are installed.
>
>I'd say that it's up to the application to deal with this problem.
>
>An application which requires lots and lots of plugins could
>define a registration protocol that does not require loading
>all plugins at scanning time.

It's not fixable at the application level, at least in Twisted's plugin 
system.  It sounds like Zope's system has the same problem, but all I 
know of that system is what you wrote above.  The cost increases with 
the number of plugins installed on the system, not the number of plugins 
the application wants to load.

Jean-Paul

From fuzzyman at voidspace.org.uk  Mon Aug  2 16:00:33 2010
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Mon, 02 Aug 2010 15:00:33 +0100
Subject: [Python-Dev] proto-pep: plugin proposal (for unittest)
In-Reply-To: <f9203038-f94b-eb28-b9af-d3200dc27db9@me.com>
References: <f9203038-f94b-eb28-b9af-d3200dc27db9@me.com>
Message-ID: <4C56CF81.20803@voidspace.org.uk>

On 02/08/2010 14:34, Ronald Oussoren wrote:
>
>
> On 02 Aug, 2010,at 01:00 PM, Michael Foord <fuzzyman at voidspace.org.uk> 
> wrote:
>
>> > The only apple one that is actually used is the .CFUserTextEncoding
>> > file, I have an .Xcode in my home as well but that is empty and last
>> > updated in 2007. AFAIK current versions of Xcode store preferences in
>> > ~/Library/Preferences. Most of the other ones are ports of unix tools
>> > and store junk in the standard unix location for storing
>> > configuration. Try edit one without resorting to the command-line
>>
>> The configuration files we are discussing are for command line tools -
>> so I don't think that having to resort to the command line is a
>> disadvantage at all. If users don't / can't use the command line then
>> they *won't* want to edit these files anyway.
> Not being comfortable at the command-line is not the same as not 
> wanting to edit the global configuration of unittest or distutils.
>

But both of those are primarily command line tools. A basic ability to 
use the command line is a prerequisite of wanting to configure them.

I would be interested in hearing from other Mac users as to where they 
would look for configuration files for command line tools - in ~ or in 
~/Library/Preferences?

Michael

> Anyway, does that mean that the configuration should move if I create 
> a patch for IDLE that allows you the manage the unittest configuration 
> through a GUI?
>
>>
>> If they are used to the command line then ~/.python32/distutils.cfg is
>> going to be a very natural place for them.
> That location isn't natural for me. If we invent a new location for 
> python-related configuration file we might as well do it properly and 
> follow platform conventions.
>
> The MacOSX conventions are described here 
> <http://developer.apple.com/mac/library/documentation/MacOSX/Conceptual/BPFileSystem/BPFileSystem.html#//apple_ref/doc/uid/10000185-SW1>.
>
> Macosx-is-not-a-crappy-linux-ly yours,
>
>   Ronald


-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies ("BOGUS AGREEMENTS") that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100802/57327afb/attachment-0001.html>

From rdmurray at bitdance.com  Mon Aug  2 16:24:58 2010
From: rdmurray at bitdance.com (R. David Murray)
Date: Mon, 02 Aug 2010 10:24:58 -0400
Subject: [Python-Dev] proto-pep: plugin proposal (for unittest)
In-Reply-To: <8a1ff5c3-3538-cbde-eece-ecc098fd2927@me.com>
References: <8a1ff5c3-3538-cbde-eece-ecc098fd2927@me.com>
Message-ID: <20100802142458.44DEC219300@kimball.webabinitio.net>

(Ronald, the text version of your message was very difficult to sort
through and read, because all of the quoting information was lost.
Just thought you'd want to know.)

What I hear Glyph saying is that we should support looking in *both*
locations for configuration info on OSX, and I don't see a downside to
that.  Most unix applications look in multiple places for configuration
info.

Michael seems to be arguing for not using the standard OSX locations
because the Finder can't edit them anyway.  Is that true?

--
R. David Murray                                      www.bitdance.com

From rrr at ronadam.com  Mon Aug  2 16:25:06 2010
From: rrr at ronadam.com (Ron Adam)
Date: Mon, 02 Aug 2010 09:25:06 -0500
Subject: [Python-Dev] No response to posts
In-Reply-To: <878w4ptmrd.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <i32g9g$ouf$1@dough.gmane.org>	<AANLkTi=5xfXtYbRbe8ZD5XmG7vApWZhbnm-vk3qq13Xg@mail.gmail.com>	<i338g6$9o7$1@dough.gmane.org>	<AANLkTin7oUUcOZFqBQnRe+0PFSPj78bEtD9p179YMe4Z@mail.gmail.com>	<4C555E24.9040007@netwok.org>
	<i34v48$8lc$1@dough.gmane.org>	<i350gg$blm$1@dough.gmane.org>
	<878w4ptmrd.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <i36kg3$1ql$1@dough.gmane.org>



On 08/02/2010 03:57 AM, Stephen J. Turnbull wrote:
> Ron Adam writes:
>
>   >  Something that may be more useful, is a "no activity" search field
>   >  with choices of day, week, month, year, etc... and make the output
>   >  sortable on time without activity.
>
> That's exactly what a sort on date of activity gives you, though, and
> it can be from longest down.

Yes, but when I do it, I either get a single specific day, or 2700 issues.


> Also, I think that most of the "date" fields actually allow ranges
> (iirc something like "today - 1 year, today" works, I've never
> actually used them), but I don't think this can be easily negated in
> the stock Roundup.  What could be done though is something like
> "created Jan 1 1970, today - 2 years AND open" to find bugs that have
> been hanging fire for more than two years.

Have you tried it?  I tried various different spelling and could only enter 
one specific day, "today" works, but "1 month" or "2 years" doesn't.

What does work is entering a partial date, ie...  2010-07 for all issues 
with activity this july. Or 2010 for all issues with activity this year.

Ron


From barry at python.org  Mon Aug  2 16:15:01 2010
From: barry at python.org (Barry Warsaw)
Date: Mon, 2 Aug 2010 10:15:01 -0400
Subject: [Python-Dev] Python 2.6.6 rc 1 planned for today
Message-ID: <20100802101501.455f173f@heresy>

Hi folks,

Don't forget that I am planning to cut Python 2.6.6 rc 1 later today (probably
starting at around 2200 UTC).  We have a number of release blockers currently
reported:

http://bugs.python.org/issue?@columns=title,id,activity,versions,assignee&@sort=activity&@group=priority&@filter=priority,status&@pagesize=50&@startwith=0&priority=1&status=1&@dispname=Showstoppers

Feel free to ping me on irc (freenode @ #python-dev) or follow up here if you
have any input on these.

I'll send the usually notes out to the committers list when I'm ready to
freeze the tree.

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100802/16bfdf1b/attachment.pgp>

From barry at python.org  Mon Aug  2 16:35:48 2010
From: barry at python.org (Barry Warsaw)
Date: Mon, 2 Aug 2010 10:35:48 -0400
Subject: [Python-Dev] [RELEASED] Python 3.2 alpha 1
In-Reply-To: <20100802120931.76c3b094@pitrou.net>
References: <4C55409B.5000409@python.org>
	<AANLkTik5JUSkTem0myE-2MWJ3i_m3MFthr4sKp35kbOz@mail.gmail.com>
	<i35nm8$s4p$1@dough.gmane.org> <20100802120931.76c3b094@pitrou.net>
Message-ID: <20100802103548.25ced10d@heresy>

On Aug 02, 2010, at 12:09 PM, Antoine Pitrou wrote:

>On Mon, 02 Aug 2010 08:10:58 +0200
>Georg Brandl <g.brandl at gmx.net> wrote:
>> Thanks, Benjamin!  I'd also like to thank Martin and Ronald for the
>> prompt binaries, and the folks of #python-dev for support.  RMing
>> was a pleasant experience so far.
>
>Are you already trying to lure other people into replacing you?

Whitewashing the fence is *soooooo* much fun! :)

Congratulations Georg.  Benjamin and I have now been authorized to show you
the secret PSU handsha
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100802/d56f5647/attachment.pgp>

From fuzzyman at voidspace.org.uk  Mon Aug  2 16:37:08 2010
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Mon, 02 Aug 2010 15:37:08 +0100
Subject: [Python-Dev] proto-pep: plugin proposal (for unittest)
In-Reply-To: <20100802142458.44DEC219300@kimball.webabinitio.net>
References: <8a1ff5c3-3538-cbde-eece-ecc098fd2927@me.com>
	<20100802142458.44DEC219300@kimball.webabinitio.net>
Message-ID: <4C56D814.4030804@voidspace.org.uk>

On 02/08/2010 15:24, R. David Murray wrote:
> (Ronald, the text version of your message was very difficult to sort
> through and read, because all of the quoting information was lost.
> Just thought you'd want to know.)
>
> What I hear Glyph saying is that we should support looking in *both*
> locations for configuration info on OSX, and I don't see a downside to
> that.  Most unix applications look in multiple places for configuration
> info.
>    

That adds extra complexity to the implementation of the configuration 
system. If it uses the first one it finds which order does it look in, 
if we have tools that create the file which location does it create it 
in and so on.

> Michael seems to be arguing for not using the standard OSX locations
> because the Finder can't edit them anyway.  Is that true?
>    
I am saying that Ronald's suggestion is *not* a natural location for 
user editable configuration files - as far as I can tell I have no user 
editable files there and plenty in ~/.something. Ronald himself said 
that the location he is specifying is the standard location for 
configuration / preference files created and used by *gui* tools, and 
files in that location are not usually intended to be user editable.

I don't believe a Mac user basically competent at the command line is 
*likely* to go looking in the gui preferences location for these config 
files and I think they would easily find them in ~. This is backed up 
the number of existing programs that use this convention on Mac OS X. It 
*is* a widely used convention on Mac OS X to use ~/.appname for 
configuration files. Applications like mercurial use this location on 
the Mac for example.

Ronald was wrong when he said that the only configuration file in ~ used 
by the Mac itself is .CFUserTextEncoding. Terminal (the Mac OS X command 
line) has a user editable config file which it stores in ~.

The issue with the finder is that by default . files and directories 
aren't shown and so they wouldn't be editable from the finder. As basic 
willingness to use the command line is a prerequisite for *wanting* to 
edit these files I don't see this as an issue. A user unfamiliar with 
the command line is not likely to guess the correct location for these 
files if we put them elsewhere, so they are going to have to refer to 
some documentation anyway.

Michael


> --
> R. David Murray                                      www.bitdance.com
>    


-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (?BOGUS AGREEMENTS?) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.



From barry at python.org  Mon Aug  2 17:08:10 2010
From: barry at python.org (Barry Warsaw)
Date: Mon, 2 Aug 2010 11:08:10 -0400
Subject: [Python-Dev] python-checkins Reply-To now set for python-dev
Message-ID: <20100802110810.06d2b9fd@heresy>

Over in #python-dev, Georg reminded us of a change to the python-checkins
mailing list that was discussed a few weeks ago:

    http://mail.python.org/pipermail/python-dev/2010-July/101853.html

Despite the mild preference of redirecting python-checkins to
python-committers, I noticed that the list was already set up to redirect to
python-dev (but the Reply-To munging was disabled).  I've now re-enabled
redirects of python-checkins to python-dev.  I think it's better to default to
more openness and it's not really that much traffic anyway.

If it gets obnoxious we can narrow things, but let's see how it goes.

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100802/5d076515/attachment.pgp>

From merwok at netwok.org  Mon Aug  2 17:08:57 2010
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Mon, 02 Aug 2010 17:08:57 +0200
Subject: [Python-Dev] PEP 376 proposed changes for basic plugins support
In-Reply-To: <20100802123145.2305.1286368223.divmod.xquotient.3@localhost.localdomain>
References: <AANLkTinyjMkF2n91zS+48n6B_gkp9szW_bH0XJgTDh7D@mail.gmail.com>	<4C55FF0F.3010702@voidspace.org.uk>	<AANLkTim1af-zWEYF4U-vTr6d+8HkqFCycMVmQYsqpDcN@mail.gmail.com>	<4C5609A3.3090008@voidspace.org.uk>	<AANLkTimU-OUh8fzFoRvHMsQOqVa+jsFTfPyZKeY=heVg@mail.gmail.com>	<20100802010616.5FD133A4758@sparrow.telecommunity.com>	<AANLkTi=UDktBHXeQTU6_ouPk2sfnmhztMLY9yjzZJHP7@mail.gmail.com>	<4C56B846.9090009@egenix.com>
	<20100802123145.2305.1286368223.divmod.xquotient.3@localhost.localdomain>
Message-ID: <4C56DF89.9070305@netwok.org>

Le 02/08/2010 14:31, exarkun at twistedmatrix.com a ?crit :
> On 12:21 pm, mal at egenix.com wrote:
>> Do we really need to make Python packaging even more complicated by
>> adding support for application-specific plugin mechanisms ?
>>
>> Packages can already work as application plugins by simply defining
>> a plugins namespace package and then placing the plugin packages
>> into that namespace. [...]
>
> This is also roughly how Twisted's plugin system works.  One drawback, 
> though, is that it means potentially executing a large amount of Python 
> in order to load plugins.  This can build up to a significant 
> performance issue as more and more plugins are installed.

If namespace packages make it into Python, they would indeed solve a
part of the problem in a nice, generic way. Regarding the performance
issue, I wonder if functions in pkgutil or importlib could allow one to
iterate over the plugins (i.e. submodules and subpackages of the
namespace package) without actually loading then. We would get only
their names though, not their description or any other information
useful to decide to activate them or not. Maybe importing is the way to
go, with a doc recommendation that people make their plugins subpackages
with an __init__ module containing only a docstring.

Regards


From glyph at twistedmatrix.com  Mon Aug  2 17:25:15 2010
From: glyph at twistedmatrix.com (Glyph Lefkowitz)
Date: Mon, 2 Aug 2010 11:25:15 -0400
Subject: [Python-Dev] PEP 376 proposed changes for basic plugins support
In-Reply-To: <20100802135354.2305.1593696105.divmod.xquotient.73@localhost.localdomain>
References: <AANLkTinyjMkF2n91zS+48n6B_gkp9szW_bH0XJgTDh7D@mail.gmail.com>
	<4C55FF0F.3010702@voidspace.org.uk>
	<AANLkTim1af-zWEYF4U-vTr6d+8HkqFCycMVmQYsqpDcN@mail.gmail.com>
	<4C5609A3.3090008@voidspace.org.uk>
	<AANLkTimU-OUh8fzFoRvHMsQOqVa+jsFTfPyZKeY=heVg@mail.gmail.com>
	<20100802010616.5FD133A4758@sparrow.telecommunity.com>
	<AANLkTi=UDktBHXeQTU6_ouPk2sfnmhztMLY9yjzZJHP7@mail.gmail.com>
	<4C56B846.9090009@egenix.com>
	<20100802123145.2305.1286368223.divmod.xquotient.3@localhost.localdomain>
	<4C56C7D1.7070003@egenix.com>
	<20100802135354.2305.1593696105.divmod.xquotient.73@localhost.localdomain>
Message-ID: <2BDF26CE-EA05-4FDF-A902-D77060C3581F@twistedmatrix.com>


On Aug 2, 2010, at 9:53 AM, exarkun at twistedmatrix.com wrote:

> On 01:27 pm, mal at egenix.com wrote:
>> exarkun at twistedmatrix.com wrote:
>>> On 12:21 pm, mal at egenix.com wrote:
>>>> 
>>>> See Zope for an example of how well this simply mechanism works out in
>>>> practice: it simply scans the "Products" namespace for sub-packages and
>>>> then loads each sub-package it finds to have it register itself with
>>>> Zope.
>>> 
>>> This is also roughly how Twisted's plugin system works.  One drawback,
>>> though, is that it means potentially executing a large amount of Python
>>> in order to load plugins.  This can build up to a significant
>>> performance issue as more and more plugins are installed.
>> 
>> I'd say that it's up to the application to deal with this problem.
>> 
>> An application which requires lots and lots of plugins could
>> define a registration protocol that does not require loading
>> all plugins at scanning time.
> 
> It's not fixable at the application level, at least in Twisted's plugin system.  It sounds like Zope's system has the same problem, but all I know of that system is what you wrote above.  The cost increases with the number of plugins installed on the system, not the number of plugins the application wants to load.

We do have a plan to address this in Twisted's plugin system (eventually): <http://twistedmatrix.com/trac/ticket/3773>, although I'm not sure if that's relevant to the issue at hand.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100802/f1b32f88/attachment.html>

From breamoreboy at yahoo.co.uk  Mon Aug  2 17:29:57 2010
From: breamoreboy at yahoo.co.uk (Mark Lawrence)
Date: Mon, 02 Aug 2010 16:29:57 +0100
Subject: [Python-Dev] [RELEASED] Python 3.2 alpha 1
In-Reply-To: <4C55409B.5000409@python.org>
References: <4C55409B.5000409@python.org>
Message-ID: <i36o9o$lto$1@dough.gmane.org>

On 01/08/2010 10:38, Georg Brandl wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On behalf of the Python development team, I'm happy to announce the
> first alpha preview release of Python 3.2.
>
> Python 3.2 is a continuation of the efforts to improve and stabilize the
> Python 3.x line.  Since the final release of Python 2.7, the 2.x line
> will only receive bugfixes, and new features are developed for 3.x only.
>
> Since PEP 3003, the Moratorium on Language Changes, is in effect, there
> are no changes in Python's syntax and built-in types in Python 3.2.
> Development efforts concentrated on the standard library and support for
> porting code to Python 3.  Highlights are:
>
> * numerous improvements to the unittest module
> * PEP 3147, support for .pyc repository directories
> * an overhauled GIL implementation that reduces contention
> * many consistency and behavior fixes for numeric operations
> * countless fixes regarding string/unicode issues; among them full
>    support for a bytes environment (filenames, environment variables)
> * a sysconfig module to access configuration information
> * a pure-Python implementation of the datetime module
> * additions to the shutil module, among them archive file support
> * improvements to pdb, the Python debugger
>
> For an extensive list of changes in 3.2, see Misc/NEWS in the Python
> distribution.
>
> To download Python 3.2 visit:
>
>       http://www.python.org/download/releases/3.2/
>
> 3.2 documentation can be found at:
>
>       http://docs.python.org/3.2/
>
> Please consider trying Python 3.2 with your code and reporting any bugs
> you may notice to:
>
>       http://bugs.python.org/
>
>
> Enjoy!
>
> - --
> Georg Brandl, Release Manager
> georg at python.org
> (on behalf of the entire python-dev team and 3.2's contributors)
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.16 (GNU/Linux)
>
> iEYEARECAAYFAkxVQJsACgkQN9GcIYhpnLBxIgCcCiVu/QUkFf0bYM2Vmi8St3mZ
> 2N4An04q36lr47OA+bslqG/4Zj7ZwVOX
> =iL8N
> -----END PGP SIGNATURE-----

If I had things my way I would immediately award you a Blue Peter Gold 
Badge. [1]

Kindest regards.

Mark Lawrence.

[1]  Blue Peter is the longest running kids' programme in the world 
having started on the BBC in 1958.


From exarkun at twistedmatrix.com  Mon Aug  2 17:53:42 2010
From: exarkun at twistedmatrix.com (exarkun at twistedmatrix.com)
Date: Mon, 02 Aug 2010 15:53:42 -0000
Subject: [Python-Dev] PEP 376 proposed changes for basic plugins support
In-Reply-To: <4C56DF89.9070305@netwok.org>
References: <AANLkTinyjMkF2n91zS+48n6B_gkp9szW_bH0XJgTDh7D@mail.gmail.com>
	<4C55FF0F.3010702@voidspace.org.uk>
	<AANLkTim1af-zWEYF4U-vTr6d+8HkqFCycMVmQYsqpDcN@mail.gmail.com>
	<4C5609A3.3090008@voidspace.org.uk>
	<AANLkTimU-OUh8fzFoRvHMsQOqVa+jsFTfPyZKeY=heVg@mail.gmail.com>
	<20100802010616.5FD133A4758@sparrow.telecommunity.com>
	<AANLkTi=UDktBHXeQTU6_ouPk2sfnmhztMLY9yjzZJHP7@mail.gmail.com>
	<4C56B846.9090009@egenix.com>
	<20100802123145.2305.1286368223.divmod.xquotient.3@localhost.localdomain>
	<4C56DF89.9070305@netwok.org>
Message-ID: <20100802155342.2305.1818831597.divmod.xquotient.82@localhost.localdomain>

On 03:08 pm, merwok at netwok.org wrote:
>Le 02/08/2010 14:31, exarkun at twistedmatrix.com a ?crit :
>>On 12:21 pm, mal at egenix.com wrote:
>>>Do we really need to make Python packaging even more complicated by
>>>adding support for application-specific plugin mechanisms ?
>>>
>>>Packages can already work as application plugins by simply defining
>>>a plugins namespace package and then placing the plugin packages
>>>into that namespace. [...]
>>
>>This is also roughly how Twisted's plugin system works.  One drawback,
>>though, is that it means potentially executing a large amount of 
>>Python
>>in order to load plugins.  This can build up to a significant
>>performance issue as more and more plugins are installed.
>
>If namespace packages make it into Python, they would indeed solve a
>part of the problem in a nice, generic way.

I don't think this solves the problem.  Twisted's plugin system already 
uses namespace packages.  It helps slightly, by spreading out your 
plugins, but you can still end up with lots of plugins in a particular 
namespace.
>Regarding the performance
>issue, I wonder if functions in pkgutil or importlib could allow one to
>iterate over the plugins (i.e. submodules and subpackages of the
>namespace package) without actually loading then. We would get only
>their names though, not their description or any other information
>useful to decide to activate them or not.

The trick is to continue to provide enough information so that the code 
iterating over the data can make a correct decision.  It's not clear 
that names are enough.
>Maybe importing is the way to
>go, with a doc recommendation that people make their plugins 
>subpackages
>with an __init__ module containing only a docstring.
>
>Regards

Jean-Paul

From ronaldoussoren at mac.com  Mon Aug  2 18:15:44 2010
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Mon, 02 Aug 2010 18:15:44 +0200
Subject: [Python-Dev] proto-pep: plugin proposal (for unittest)
In-Reply-To: <20100802142458.44DEC219300@kimball.webabinitio.net>
References: <8a1ff5c3-3538-cbde-eece-ecc098fd2927@me.com>
	<20100802142458.44DEC219300@kimball.webabinitio.net>
Message-ID: <40CAA957-5AA2-494B-8A08-70E67F156142@mac.com>


On 2 Aug, 2010, at 16:24, R. David Murray wrote:

> (Ronald, the text version of your message was very difficult to sort
> through and read, because all of the quoting information was lost.
> Just thought you'd want to know.)

I'll stop using the mobile-me webmail client for lists, it seems to mess things up.

> 
> What I hear Glyph saying is that we should support looking in *both*
> locations for configuration info on OSX, and I don't see a downside to
> that.  Most unix applications look in multiple places for configuration
> info.

A lot of tools seem to look both in a system location and a per user location (such as /etc/profile and ~/.profile).

OSX ads a 3th level to that, although I have never used that myself (technically there are 4 levels, but that isn't important unless you are Apple).

> 
> Michael seems to be arguing for not using the standard OSX locations
> because the Finder can't edit them anyway.  Is that true?

The Finder can open OSX locations just fine, but you cannot see dot-files (or -directories) in the Finder.

I won't argue this anymore, at least not this week. I'll work around the issue in my private tree if that's what's needed.

Ronald

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3567 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100802/ad3c0e93/attachment.bin>

From pje at telecommunity.com  Mon Aug  2 18:18:35 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Mon, 02 Aug 2010 12:18:35 -0400
Subject: [Python-Dev] PEP 376 proposed changes for basic plugins support
In-Reply-To: <20100802135354.2305.1593696105.divmod.xquotient.73@localho
	st.localdomain>
References: <AANLkTinyjMkF2n91zS+48n6B_gkp9szW_bH0XJgTDh7D@mail.gmail.com>
	<4C55FF0F.3010702@voidspace.org.uk>
	<AANLkTim1af-zWEYF4U-vTr6d+8HkqFCycMVmQYsqpDcN@mail.gmail.com>
	<4C5609A3.3090008@voidspace.org.uk>
	<AANLkTimU-OUh8fzFoRvHMsQOqVa+jsFTfPyZKeY=heVg@mail.gmail.com>
	<20100802010616.5FD133A4758@sparrow.telecommunity.com>
	<AANLkTi=UDktBHXeQTU6_ouPk2sfnmhztMLY9yjzZJHP7@mail.gmail.com>
	<4C56B846.9090009@egenix.com>
	<20100802123145.2305.1286368223.divmod.xquotient.3@localhost.localdomain>
	<4C56C7D1.7070003@egenix.com>
	<20100802135354.2305.1593696105.divmod.xquotient.73@localhost.localdomain>
Message-ID: <20100802161832.BA7FF3A4108@sparrow.telecommunity.com>

At 01:53 PM 8/2/2010 +0000, exarkun at twistedmatrix.com wrote:
>On 01:27 pm, mal at egenix.com wrote:
>>exarkun at twistedmatrix.com wrote:
>>>This is also roughly how Twisted's plugin system works.  One drawback,
>>>though, is that it means potentially executing a large amount of Python
>>>in order to load plugins.  This can build up to a significant
>>>performance issue as more and more plugins are installed.
>>
>>I'd say that it's up to the application to deal with this problem.
>>
>>An application which requires lots and lots of plugins could
>>define a registration protocol that does not require loading
>>all plugins at scanning time.

Just for the record, solving this problem is precisely what entry 
points are for: they provide a discovery mechanism that doesn't 
require importing anything until you actually need it.

>It's not fixable at the application level, at least in Twisted's 
>plugin system.  It sounds like Zope's system has the same problem, 
>but all I know of that system is what you wrote above.

I don't know about Zope in general, but there are certainly Zope 
corp. projects that use entry points instead of namespaces (buildout, 
for one), and I believe that there's been a long time push to move 
third-party code out of the common namespace package.  i.e., AFAIK, 
Zope 3 doesn't use package namespaces as a primary method of extension.


>   The cost increases with the number of plugins installed on the 
> system, not the number of plugins the application wants to load.

Pretty much any plugin discovery system is going to scale that way, 
but entry points only require file reads rather than imports, and 
have a shared cache for all code in use by the application.  So if, 
say, Twisted uses entry points and an application running on Twisted 
also uses entry points, the loading cost is only paid once for both 
sets of entry points inspected.


From breamoreboy at yahoo.co.uk  Mon Aug  2 18:21:24 2010
From: breamoreboy at yahoo.co.uk (Mark Lawrence)
Date: Mon, 02 Aug 2010 17:21:24 +0100
Subject: [Python-Dev] No response to posts
In-Reply-To: <AANLkTinpB7yVhMSQ=Q9hMCA+SnF4p+zNH98-GZd4ZP+w@mail.gmail.com>
References: <i32g9g$ouf$1@dough.gmane.org>	<4C54C5A4.6080409@netwok.org>
	<AANLkTinpB7yVhMSQ=Q9hMCA+SnF4p+zNH98-GZd4ZP+w@mail.gmail.com>
Message-ID: <i36ra7$353$1@dough.gmane.org>

On 02/08/2010 03:54, Benjamin Peterson wrote:
> 2010/7/31 ?ric Araujo<winston at netwok.org>:
>> Good call.
>>
>> Alternative idea: Have a new status ?unread? to make searching easier
>> for bug people. Or a predefined custom search for nosy_count == 1.
>
> Please, let's stop messing with the tracker for everything. I think
> the current set up works reasonably well, and we should focus on the
> real problem: manpower
>

I disagree entirely with this comment.  Perhaps we should simply agree 
to disagree, but I can't see how having issues that have been sitting 
for years without any response at all ties in with "the current set up 
works reasonably well".  The number was over 500 when Terry Reedy put 
his orphan tracker request on c.l.py.  IMHO a reply along the lines of 
"bugger off we're far too busy" would be better than nothing.  Failing 
that the simple "please provide a code and unit test patch" seems to 
work quite well.  Failing that "I'm going to close this because nobody 
is interested" works extremely well in waking people up! :)  All of 
these are better than complete silence.  I also believe that the latter 
of my suggestions should be used when the OP has shown no interest in 
moving the issue despite being asked to do so.

Just me tuppence worth.

Mark Lawrence.



From pje at telecommunity.com  Mon Aug  2 18:28:54 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Mon, 02 Aug 2010 12:28:54 -0400
Subject: [Python-Dev] PEP 376 proposed changes for basic plugins support
Message-ID: <20100802162852.0F04E3A4108@sparrow.telecommunity.com>

At 01:10 PM 8/2/2010 +0200, Tarek Ziad? wrote:
>I don't have a specific example in mind, and I must admit that if an
>application does the right thing
>(provide the right configuration file), this activate feature is not
>useful at all. So it seems to be a bad idea.

Well, it's not a *bad* idea as such; actually, having conventions for 
such configuration, and libraries that help to implement the 
convention are a *good* idea, and I support it.  I just don't think 
it makes much sense to *impose* the convention on the app developers; 
there are, after all, use cases that don't need the extra configuration.

Setuptools was mainly designed to support the "application plugin 
directory" model for invasive sorts of plugins, and the "global 
plugin availability" model for the kind of plugins that a user has to 
explicitly select (e.g. file type converters, special distutils 
commands, etc.).  However, there are definitely use cases for 
"user-configured plugins", and the apps that do it generally use some 
sort of configuration file to identify which entry points they'll actually use.


>IOW, have entry points like setuptools provides, but in a metadata
>field instead of a entry_points.txt file.

May I suggest, then, that we keep entry_points.txt, but simply 
provide a summary in PKG-INFO?  (i.e., list the groups and names provided)

This would still make it easy for human browsing/discovery of entry 
points on PyPI, but it would allow easy forward/backward 
compatibility between setuptools and distutils2, while also providing 
faster lookup of entry points (because you can skip distributions 
that don't have an entry points file, vs. having to parse *every* 
PKG-INFO file).

Or to put it another way, when I implement PEP 376 support in 
setuptools 0.7, I'll only have to change the name of the .egg-info 
directory and copy the entry point summary into PKG-INFO.  And, even 
more to the point, people who define entry points with distutils2 
will then be able to have them work with setuptools-based projects, 
and vice versa, helping to smooth the transition.


From ralf at brainbot.com  Mon Aug  2 18:39:11 2010
From: ralf at brainbot.com (Ralf Schmitt)
Date: Mon, 02 Aug 2010 18:39:11 +0200
Subject: [Python-Dev] No response to posts
In-Reply-To: <AANLkTinpB7yVhMSQ=Q9hMCA+SnF4p+zNH98-GZd4ZP+w@mail.gmail.com>
	(Benjamin Peterson's message of "Sun, 1 Aug 2010 21:54:18 -0500")
References: <i32g9g$ouf$1@dough.gmane.org> <4C54C5A4.6080409@netwok.org>
	<AANLkTinpB7yVhMSQ=Q9hMCA+SnF4p+zNH98-GZd4ZP+w@mail.gmail.com>
Message-ID: <87r5ihm0k0.fsf@muni.brainbot.com>

Benjamin Peterson <benjamin at python.org> writes:

> Please, let's stop messing with the tracker for everything. I think
> the current set up works reasonably well, and we should focus on the
> real problem: manpower

Ignoring issues (probably even with some patches attached) will drive
contributors away. That's not the way to increase manpower.

- Ralf

From breamoreboy at yahoo.co.uk  Mon Aug  2 18:50:27 2010
From: breamoreboy at yahoo.co.uk (Mark Lawrence)
Date: Mon, 02 Aug 2010 17:50:27 +0100
Subject: [Python-Dev] No response to posts
In-Reply-To: <87r5ihm0k0.fsf@muni.brainbot.com>
References: <i32g9g$ouf$1@dough.gmane.org>
	<4C54C5A4.6080409@netwok.org>	<AANLkTinpB7yVhMSQ=Q9hMCA+SnF4p+zNH98-GZd4ZP+w@mail.gmail.com>
	<87r5ihm0k0.fsf@muni.brainbot.com>
Message-ID: <i36t0m$9sj$1@dough.gmane.org>

On 02/08/2010 17:39, Ralf Schmitt wrote:
> Benjamin Peterson<benjamin at python.org>  writes:
>
>> Please, let's stop messing with the tracker for everything. I think
>> the current set up works reasonably well, and we should focus on the
>> real problem: manpower
>
> Ignoring issues (probably even with some patches attached) will drive
> contributors away. That's not the way to increase manpower.
>
> - Ralf
+1

Mark Lawrence.


From brian.curtin at gmail.com  Mon Aug  2 18:54:45 2010
From: brian.curtin at gmail.com (Brian Curtin)
Date: Mon, 2 Aug 2010 11:54:45 -0500
Subject: [Python-Dev] No response to posts
In-Reply-To: <87r5ihm0k0.fsf@muni.brainbot.com>
References: <i32g9g$ouf$1@dough.gmane.org> <4C54C5A4.6080409@netwok.org>
	<AANLkTinpB7yVhMSQ=Q9hMCA+SnF4p+zNH98-GZd4ZP+w@mail.gmail.com>
	<87r5ihm0k0.fsf@muni.brainbot.com>
Message-ID: <AANLkTikDM0nCVT1S9Jg-ZySTnysBvK0qk0Jpta8WZG82@mail.gmail.com>

On Mon, Aug 2, 2010 at 11:39, Ralf Schmitt <ralf at brainbot.com> wrote:

> Benjamin Peterson <benjamin at python.org> writes:
>
> > Please, let's stop messing with the tracker for everything. I think
> > the current set up works reasonably well, and we should focus on the
> > real problem: manpower
>
> Ignoring issues (probably even with some patches attached) will drive
> contributors away. That's not the way to increase manpower.
>
> - Ralf


Overall the "no response" query just passes the buck. Let's say we get that
query down to zero issues. What does that give us? Now we have 500 issues
with 2 responses. Sure, it makes further correspondence more likely, but
it's not solving any real issues and making any measurably significant
impact.

While I do think the "no response" query can be helpful, let's not attribute
too much value to tiny tweaks of the tracker and reporting. Benjamin is
right -- manpower is where we'll benefit the most, not in the manner we
paint the current issue situation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100802/b79361f2/attachment.html>

From ianb at colorstudy.com  Mon Aug  2 18:57:23 2010
From: ianb at colorstudy.com (Ian Bicking)
Date: Mon, 2 Aug 2010 11:57:23 -0500
Subject: [Python-Dev] PEP 376 proposed changes for basic plugins support
In-Reply-To: <AANLkTinyjMkF2n91zS+48n6B_gkp9szW_bH0XJgTDh7D@mail.gmail.com>
References: <AANLkTinyjMkF2n91zS+48n6B_gkp9szW_bH0XJgTDh7D@mail.gmail.com>
Message-ID: <AANLkTi=n3gR=pDb90Es0h+jHL72jcU8g-TX3fPKLnXZY@mail.gmail.com>

Just to add a general opinion in here:

Having worked with Setuptools' entry points, and a little with some Zope
pluginish systems (Products.*, which I don't think anyone liked much, and
some ways ZCML is used is pluginish), I'm not very excited about these.  The
plugin system that causes the least confusion and yet seems to accomplish
everything it needs is just listing objects in configuration -- nothing gets
activated implicitly with installation, and names are Python package/object
names without indirection.  The only thing I'd want to add is the ability to
also point to files, as a common use for plugins is adding ad hoc
functionality to an application, and the overhead of package creation isn't
always called for.  hg for example seems both simple and general enough, and
it doesn't use anything fancy.

Purely for the purpose of discovery and documentation it might be helpful to
have APIs, then some tool could show available plugins (especially if PyPI
had a query interface for this), or at least installed plugins, with the
necessary code to invoke them.

*Maybe* it would make sense to generalize the discovery of plugin types, so
that you can simply refer to an object and the application can determine
what kind of plugin it is.  But having described this, it actually doesn't
seem like a useful thing to generalize.

-- 
Ian Bicking  |  http://blog.ianbicking.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100802/14e7893f/attachment.html>

From fuzzyman at voidspace.org.uk  Mon Aug  2 19:18:29 2010
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Mon, 02 Aug 2010 18:18:29 +0100
Subject: [Python-Dev] No response to posts
In-Reply-To: <AANLkTikDM0nCVT1S9Jg-ZySTnysBvK0qk0Jpta8WZG82@mail.gmail.com>
References: <i32g9g$ouf$1@dough.gmane.org>
	<4C54C5A4.6080409@netwok.org>	<AANLkTinpB7yVhMSQ=Q9hMCA+SnF4p+zNH98-GZd4ZP+w@mail.gmail.com>	<87r5ihm0k0.fsf@muni.brainbot.com>
	<AANLkTikDM0nCVT1S9Jg-ZySTnysBvK0qk0Jpta8WZG82@mail.gmail.com>
Message-ID: <4C56FDE5.8050504@voidspace.org.uk>

On 02/08/2010 17:54, Brian Curtin wrote:
> On Mon, Aug 2, 2010 at 11:39, Ralf Schmitt <ralf at brainbot.com 
> <mailto:ralf at brainbot.com>> wrote:
>
>     Benjamin Peterson <benjamin at python.org
>     <mailto:benjamin at python.org>> writes:
>
>     > Please, let's stop messing with the tracker for everything. I think
>     > the current set up works reasonably well, and we should focus on the
>     > real problem: manpower
>
>     Ignoring issues (probably even with some patches attached) will drive
>     contributors away. That's not the way to increase manpower.
>
>     - Ralf
>
>
> Overall the "no response" query just passes the buck. Let's say we get 
> that query down to zero issues. What does that give us? Now we have 
> 500 issues with 2 responses. Sure, it makes further correspondence 
> more likely, but it's not solving any real issues and making any 
> measurably significant impact.
>

Sure it could make a difference. People who submit issues will 
appreciate *some* response a great deal more than no response. More than 
that, if we have people dedicated to looking at new issues then we are 
more likely to *resolve* some that would otherwise "slip through the net".


> While I do think the "no response" query can be helpful, let's not 
> attribute too much value to tiny tweaks of the tracker and reporting. 
> Benjamin is right -- manpower is where we'll benefit the most, not in 
> the manner we paint the current issue situation.

Sure. *Part* of drawing in more manpower can be engaging with those 
submitting issues and seeing if we can get them to post patches and / or 
tests - and suck them as far into Python development as we possibly can. 
;-) For many people submitting an issue may be their first contact with 
Python developers and the Python development process (just as for others 
posting to Python-dev will be their first contact - even if they really 
should be posting to comp.lang.python instead).

All the best,

Michael

>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at 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/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies ("BOGUS AGREEMENTS") that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100802/fff5033b/attachment-0001.html>

From holger.krekel at gmail.com  Mon Aug  2 20:05:03 2010
From: holger.krekel at gmail.com (Holger Krekel)
Date: Mon, 2 Aug 2010 20:05:03 +0200
Subject: [Python-Dev] PEP 376 proposed changes for basic plugins support
In-Reply-To: <AANLkTi=n3gR=pDb90Es0h+jHL72jcU8g-TX3fPKLnXZY@mail.gmail.com>
References: <AANLkTinyjMkF2n91zS+48n6B_gkp9szW_bH0XJgTDh7D@mail.gmail.com> 
	<AANLkTi=n3gR=pDb90Es0h+jHL72jcU8g-TX3fPKLnXZY@mail.gmail.com>
Message-ID: <AANLkTi=SudSNzBK9UvM7wh+cwEwuxP6Y78CDFLqcaCez@mail.gmail.com>

On Mon, Aug 2, 2010 at 6:57 PM, Ian Bicking <ianb at colorstudy.com> wrote:
> Just to add a general opinion in here:
>
> Having worked with Setuptools' entry points, and a little with some Zope
> pluginish systems (Products.*, which I don't think anyone liked much, and
> some ways ZCML is used is pluginish), I'm not very excited about these.? The
> plugin system that causes the least confusion and yet seems to accomplish
> everything it needs is just listing objects in configuration -- nothing gets
> activated implicitly with installation, and names are Python package/object
> names without indirection.

This makes it a two-step process to use a plugin: install it and then
configure it correctly to have it used.

I'd much prefer a one-step process and rather provide a way to not-use
a plugin even if installed.  The difference is e.g. with py.test that i can
point users to e.g.

  pip install pytest-figleaf
  py.test --figleaf

instead of also having to explain a configuration file, its location
and exact content or some magic attribute variables on some
classes.

TBH, i'd like to have pip handle plugins, based on metadata
(especially some data signaling something is a plugin of otherthing).
This way i only once have to teach about "pip" and people leverage
 their knowledge for installing/managing plugins.

best,
holger

> The only thing I'd want to add is the ability to
> also point to files, as a common use for plugins is adding ad hoc
> functionality to an application, and the overhead of package creation isn't
> always called for.? hg for example seems both simple and general enough, and
> it doesn't use anything fancy.
>
> Purely for the purpose of discovery and documentation it might be helpful to
> have APIs, then some tool could show available plugins (especially if PyPI
> had a query interface for this), or at least installed plugins, with the
> necessary code to invoke them.
>
> *Maybe* it would make sense to generalize the discovery of plugin types, so
> that you can simply refer to an object and the application can determine
> what kind of plugin it is.? But having described this, it actually doesn't
> seem like a useful thing to generalize.
>
> --
> Ian Bicking? |? http://blog.ianbicking.org
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/holger.krekel%40gmail.com
>
>

From mark.smith at practicalpoetry.co.uk  Mon Aug  2 20:11:46 2010
From: mark.smith at practicalpoetry.co.uk (Mark Smith)
Date: Mon, 2 Aug 2010 19:11:46 +0100
Subject: [Python-Dev] No response to posts
In-Reply-To: <4C56FDE5.8050504@voidspace.org.uk>
References: <i32g9g$ouf$1@dough.gmane.org> <4C54C5A4.6080409@netwok.org> 
	<AANLkTinpB7yVhMSQ=Q9hMCA+SnF4p+zNH98-GZd4ZP+w@mail.gmail.com> 
	<87r5ihm0k0.fsf@muni.brainbot.com>
	<AANLkTikDM0nCVT1S9Jg-ZySTnysBvK0qk0Jpta8WZG82@mail.gmail.com> 
	<4C56FDE5.8050504@voidspace.org.uk>
Message-ID: <AANLkTiknHyUkxduhzYRAKJB=hSUBi7Mu5qXXkqTKwsw4@mail.gmail.com>

If I may comment *as* a new contributor: Terry responded almost immediately
to my first issue raised, and that was a huge boost. If no-one had replied
at all, I suspect I would never have spent any more time contributing to any
part of Python. (And I contributed 8 more hours today.)

Incidentally, given that this is my first post: Hi everyone, my name's Mark
Smith. I'm a Python contractor based in Edinburgh, and my nick on IRC is
juD2k (for strange, yet dull historical reasons) :-)

--Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100802/81c6cf64/attachment.html>

From fuzzyman at voidspace.org.uk  Mon Aug  2 20:12:26 2010
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Mon, 02 Aug 2010 19:12:26 +0100
Subject: [Python-Dev] PEP 376 proposed changes for basic plugins support
In-Reply-To: <AANLkTi=SudSNzBK9UvM7wh+cwEwuxP6Y78CDFLqcaCez@mail.gmail.com>
References: <AANLkTinyjMkF2n91zS+48n6B_gkp9szW_bH0XJgTDh7D@mail.gmail.com>
	<AANLkTi=n3gR=pDb90Es0h+jHL72jcU8g-TX3fPKLnXZY@mail.gmail.com>
	<AANLkTi=SudSNzBK9UvM7wh+cwEwuxP6Y78CDFLqcaCez@mail.gmail.com>
Message-ID: <4C570A8A.1000508@voidspace.org.uk>

On 02/08/2010 19:05, Holger Krekel wrote:
> On Mon, Aug 2, 2010 at 6:57 PM, Ian Bicking<ianb at colorstudy.com>  wrote:
>    
>> Just to add a general opinion in here:
>>
>> Having worked with Setuptools' entry points, and a little with some Zope
>> pluginish systems (Products.*, which I don't think anyone liked much, and
>> some ways ZCML is used is pluginish), I'm not very excited about these.  The
>> plugin system that causes the least confusion and yet seems to accomplish
>> everything it needs is just listing objects in configuration -- nothing gets
>> activated implicitly with installation, and names are Python package/object
>> names without indirection.
>>      
> This makes it a two-step process to use a plugin: install it and then
> configure it correctly to have it used.
>
> I'd much prefer a one-step process and rather provide a way to not-use
> a plugin even if installed.  The difference is e.g. with py.test that i can
> point users to e.g.
>
>    pip install pytest-figleaf
>    py.test --figleaf
>    

How do you achieve this currently?

Michael

> instead of also having to explain a configuration file, its location
> and exact content or some magic attribute variables on some
> classes.
>
> TBH, i'd like to have pip handle plugins, based on metadata
> (especially some data signaling something is a plugin of otherthing).
> This way i only once have to teach about "pip" and people leverage
>   their knowledge for installing/managing plugins.
>
> best,
> holger
>
>    
>> The only thing I'd want to add is the ability to
>> also point to files, as a common use for plugins is adding ad hoc
>> functionality to an application, and the overhead of package creation isn't
>> always called for.  hg for example seems both simple and general enough, and
>> it doesn't use anything fancy.
>>
>> Purely for the purpose of discovery and documentation it might be helpful to
>> have APIs, then some tool could show available plugins (especially if PyPI
>> had a query interface for this), or at least installed plugins, with the
>> necessary code to invoke them.
>>
>> *Maybe* it would make sense to generalize the discovery of plugin types, so
>> that you can simply refer to an object and the application can determine
>> what kind of plugin it is.  But having described this, it actually doesn't
>> seem like a useful thing to generalize.
>>
>> --
>> Ian Bicking  |  http://blog.ianbicking.org
>>
>> _______________________________________________
>> Python-Dev mailing list
>> Python-Dev at python.org
>> http://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
>> http://mail.python.org/mailman/options/python-dev/holger.krekel%40gmail.com
>>
>>
>>      
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at 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/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (?BOGUS AGREEMENTS?) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.



From tjreedy at udel.edu  Mon Aug  2 20:27:53 2010
From: tjreedy at udel.edu (Terry Reedy)
Date: Mon, 02 Aug 2010 14:27:53 -0400
Subject: [Python-Dev] No response to posts
In-Reply-To: <AANLkTikDM0nCVT1S9Jg-ZySTnysBvK0qk0Jpta8WZG82@mail.gmail.com>
References: <i32g9g$ouf$1@dough.gmane.org>
	<4C54C5A4.6080409@netwok.org>	<AANLkTinpB7yVhMSQ=Q9hMCA+SnF4p+zNH98-GZd4ZP+w@mail.gmail.com>	<87r5ihm0k0.fsf@muni.brainbot.com>
	<AANLkTikDM0nCVT1S9Jg-ZySTnysBvK0qk0Jpta8WZG82@mail.gmail.com>
Message-ID: <i372n8$2mg$1@dough.gmane.org>

On 8/2/2010 12:54 PM, Brian Curtin wrote:
> On Mon, Aug 2, 2010 at 11:39, Ralf Schmitt <ralf at brainbot.com
> <mailto:ralf at brainbot.com>> wrote:
>
>     Benjamin Peterson <benjamin at python.org <mailto:benjamin at python.org>>
>     writes:
>
>      > Please, let's stop messing with the tracker for everything. I think
>      > the current set up works reasonably well, and we should focus on the
>      > real problem: manpower

Two months ago, I discovered and reported that about 1/5 of open issues 
had no responses. Is that 'reasonably well'? I do not remember other 
reports on that, at least not for a few years. A 'show unanswered' link 
might make it easier to recruit people to be first-responders by making 
it easier to do first response. This hardly amounts to 'messing with the 
tracker'. Rather, it is using the current mechanism by adding a link.

>     Ignoring issues (probably even with some patches attached) will drive
>     contributors away. That's not the way to increase manpower.

As a said before, I think people who have posted, certainly people who 
have had fixes committed, should get an invitation letter. One 
suggestion on that could be to click 'show unanswered' if that were 
available.

> Overall the "no response" query just passes the buck. Let's say we get
> that query down to zero issues. What does that give us? Now we have 500
> issues with 2 responses. Sure, it makes further correspondence more
> likely, but it's not solving any real issues and making any measurably
> significant impact.

If a question response elicits no answer, the issue can be closed as 
out-of-date. But several times in the past two months, first responses 
have lead to more responses from both OP and developers who watch the 
tracker message list. Some have been closed as fixed already. Example:
    http://bugs.python.org/issue3874
The OP's first response was to gripe about no response earlier. His 
second was to write an entry that Georg could cut, paste, format, and 
commit.

-- 
Terry Jan Reedy


From holger.krekel at gmail.com  Mon Aug  2 20:45:48 2010
From: holger.krekel at gmail.com (Holger Krekel)
Date: Mon, 2 Aug 2010 20:45:48 +0200
Subject: [Python-Dev] PEP 376 proposed changes for basic plugins support
In-Reply-To: <4C570A8A.1000508@voidspace.org.uk>
References: <AANLkTinyjMkF2n91zS+48n6B_gkp9szW_bH0XJgTDh7D@mail.gmail.com> 
	<AANLkTi=n3gR=pDb90Es0h+jHL72jcU8g-TX3fPKLnXZY@mail.gmail.com> 
	<AANLkTi=SudSNzBK9UvM7wh+cwEwuxP6Y78CDFLqcaCez@mail.gmail.com> 
	<4C570A8A.1000508@voidspace.org.uk>
Message-ID: <AANLkTinct3KsV5iyBBYXcp7HWqe2ZEDCYPjQauPOrXi3@mail.gmail.com>

On Mon, Aug 2, 2010 at 8:12 PM, Michael Foord <fuzzyman at voidspace.org.uk> wrote:
> On 02/08/2010 19:05, Holger Krekel wrote:
>>
>> On Mon, Aug 2, 2010 at 6:57 PM, Ian Bicking<ianb at colorstudy.com> ?wrote:
>>
>>>
>>> Just to add a general opinion in here:
>>>
>>> Having worked with Setuptools' entry points, and a little with some Zope
>>> pluginish systems (Products.*, which I don't think anyone liked much, and
>>> some ways ZCML is used is pluginish), I'm not very excited about these.
>>> ?The
>>> plugin system that causes the least confusion and yet seems to accomplish
>>> everything it needs is just listing objects in configuration -- nothing
>>> gets
>>> activated implicitly with installation, and names are Python
>>> package/object
>>> names without indirection.
>>>
>>
>> This makes it a two-step process to use a plugin: install it and then
>> configure it correctly to have it used.
>>
>> I'd much prefer a one-step process and rather provide a way to not-use
>> a plugin even if installed. ?The difference is e.g. with py.test that i
>> can
>> point users to e.g.
>>
>> ? pip install pytest-figleaf
>> ? py.test --figleaf
>>
>
> How do you achieve this currently?

it uses setuptools entrypoints, so with a setup.py param like

    entry_points = {'pytest11': ['pytest_figleaf = pytest_figleaf'],},

py.test's pluginmanager.py does:

        for ep in pkg_resources.iter_entry_points('pytest11'):
            # ... ep.name == "pytest_figleaf" <- left side of above "*=*"
            plugin = ep.load() # <- right side of above "*=*"
            # ...

best,
holger


> Michael
>
>> instead of also having to explain a configuration file, its location
>> and exact content or some magic attribute variables on some
>> classes.
>>
>> TBH, i'd like to have pip handle plugins, based on metadata
>> (especially some data signaling something is a plugin of otherthing).
>> This way i only once have to teach about "pip" and people leverage
>> ?their knowledge for installing/managing plugins.
>>
>> best,
>> holger
>>
>>
>>>
>>> The only thing I'd want to add is the ability to
>>> also point to files, as a common use for plugins is adding ad hoc
>>> functionality to an application, and the overhead of package creation
>>> isn't
>>> always called for. ?hg for example seems both simple and general enough,
>>> and
>>> it doesn't use anything fancy.
>>>
>>> Purely for the purpose of discovery and documentation it might be helpful
>>> to
>>> have APIs, then some tool could show available plugins (especially if
>>> PyPI
>>> had a query interface for this), or at least installed plugins, with the
>>> necessary code to invoke them.
>>>
>>> *Maybe* it would make sense to generalize the discovery of plugin types,
>>> so
>>> that you can simply refer to an object and the application can determine
>>> what kind of plugin it is. ?But having described this, it actually
>>> doesn't
>>> seem like a useful thing to generalize.
>>>
>>> --
>>> Ian Bicking ?| ?http://blog.ianbicking.org
>>>
>>> _______________________________________________
>>> Python-Dev mailing list
>>> Python-Dev at python.org
>>> http://mail.python.org/mailman/listinfo/python-dev
>>> Unsubscribe:
>>>
>>> http://mail.python.org/mailman/options/python-dev/holger.krekel%40gmail.com
>>>
>>>
>>>
>>
>> _______________________________________________
>> Python-Dev mailing list
>> Python-Dev at 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/
> http://www.voidspace.org.uk/blog
>
> READ CAREFULLY. By accepting and reading this email you agree, on behalf of
> your employer, to release me from all obligations and waivers arising from
> any and all NON-NEGOTIATED agreements, licenses, terms-of-service,
> shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure,
> non-compete and acceptable use policies (?BOGUS AGREEMENTS?) that I have
> entered into with your employer, its partners, licensors, agents and
> assigns, in perpetuity, without prejudice to my ongoing rights and
> privileges. You further represent that you have the authority to release me
> from any BOGUS AGREEMENTS on behalf of your employer.
>
>
>

From fuzzyman at voidspace.org.uk  Mon Aug  2 20:48:29 2010
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Mon, 02 Aug 2010 19:48:29 +0100
Subject: [Python-Dev] PEP 376 proposed changes for basic plugins support
In-Reply-To: <AANLkTinct3KsV5iyBBYXcp7HWqe2ZEDCYPjQauPOrXi3@mail.gmail.com>
References: <AANLkTinyjMkF2n91zS+48n6B_gkp9szW_bH0XJgTDh7D@mail.gmail.com>
	<AANLkTi=n3gR=pDb90Es0h+jHL72jcU8g-TX3fPKLnXZY@mail.gmail.com>
	<AANLkTi=SudSNzBK9UvM7wh+cwEwuxP6Y78CDFLqcaCez@mail.gmail.com>
	<4C570A8A.1000508@voidspace.org.uk>
	<AANLkTinct3KsV5iyBBYXcp7HWqe2ZEDCYPjQauPOrXi3@mail.gmail.com>
Message-ID: <4C5712FD.90500@voidspace.org.uk>

On 02/08/2010 19:45, Holger Krekel wrote:
> On Mon, Aug 2, 2010 at 8:12 PM, Michael Foord<fuzzyman at voidspace.org.uk>  wrote:
>    
>> On 02/08/2010 19:05, Holger Krekel wrote:
>>      
>>> On Mon, Aug 2, 2010 at 6:57 PM, Ian Bicking<ianb at colorstudy.com>    wrote:
>>>
>>>        
>>>> Just to add a general opinion in here:
>>>>
>>>> Having worked with Setuptools' entry points, and a little with some Zope
>>>> pluginish systems (Products.*, which I don't think anyone liked much, and
>>>> some ways ZCML is used is pluginish), I'm not very excited about these.
>>>>   The
>>>> plugin system that causes the least confusion and yet seems to accomplish
>>>> everything it needs is just listing objects in configuration -- nothing
>>>> gets
>>>> activated implicitly with installation, and names are Python
>>>> package/object
>>>> names without indirection.
>>>>
>>>>          
>>> This makes it a two-step process to use a plugin: install it and then
>>> configure it correctly to have it used.
>>>
>>> I'd much prefer a one-step process and rather provide a way to not-use
>>> a plugin even if installed.  The difference is e.g. with py.test that i
>>> can
>>> point users to e.g.
>>>
>>>    pip install pytest-figleaf
>>>    py.test --figleaf
>>>
>>>        
>> How do you achieve this currently?
>>      
> it uses setuptools entrypoints, so with a setup.py param like
>    

Right. I can't use that for unittest. With the new proposal we *could* 
automatically use all available plugins, but I think I prefer to only 
have plugins active that the user has chosen.

Michael

>      entry_points = {'pytest11': ['pytest_figleaf = pytest_figleaf'],},
>
> py.test's pluginmanager.py does:
>
>          for ep in pkg_resources.iter_entry_points('pytest11'):
>              # ... ep.name == "pytest_figleaf"<- left side of above "*=*"
>              plugin = ep.load() #<- right side of above "*=*"
>              # ...
>
> best,
> holger
>
>
>    
>> Michael
>>
>>      
>>> instead of also having to explain a configuration file, its location
>>> and exact content or some magic attribute variables on some
>>> classes.
>>>
>>> TBH, i'd like to have pip handle plugins, based on metadata
>>> (especially some data signaling something is a plugin of otherthing).
>>> This way i only once have to teach about "pip" and people leverage
>>>   their knowledge for installing/managing plugins.
>>>
>>> best,
>>> holger
>>>
>>>
>>>        
>>>> The only thing I'd want to add is the ability to
>>>> also point to files, as a common use for plugins is adding ad hoc
>>>> functionality to an application, and the overhead of package creation
>>>> isn't
>>>> always called for.  hg for example seems both simple and general enough,
>>>> and
>>>> it doesn't use anything fancy.
>>>>
>>>> Purely for the purpose of discovery and documentation it might be helpful
>>>> to
>>>> have APIs, then some tool could show available plugins (especially if
>>>> PyPI
>>>> had a query interface for this), or at least installed plugins, with the
>>>> necessary code to invoke them.
>>>>
>>>> *Maybe* it would make sense to generalize the discovery of plugin types,
>>>> so
>>>> that you can simply refer to an object and the application can determine
>>>> what kind of plugin it is.  But having described this, it actually
>>>> doesn't
>>>> seem like a useful thing to generalize.
>>>>
>>>> --
>>>> Ian Bicking  |  http://blog.ianbicking.org
>>>>
>>>> _______________________________________________
>>>> Python-Dev mailing list
>>>> Python-Dev at python.org
>>>> http://mail.python.org/mailman/listinfo/python-dev
>>>> Unsubscribe:
>>>>
>>>> http://mail.python.org/mailman/options/python-dev/holger.krekel%40gmail.com
>>>>
>>>>
>>>>
>>>>          
>>> _______________________________________________
>>> Python-Dev mailing list
>>> Python-Dev at 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/
>> http://www.voidspace.org.uk/blog
>>
>> READ CAREFULLY. By accepting and reading this email you agree, on behalf of
>> your employer, to release me from all obligations and waivers arising from
>> any and all NON-NEGOTIATED agreements, licenses, terms-of-service,
>> shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure,
>> non-compete and acceptable use policies (?BOGUS AGREEMENTS?) that I have
>> entered into with your employer, its partners, licensors, agents and
>> assigns, in perpetuity, without prejudice to my ongoing rights and
>> privileges. You further represent that you have the authority to release me
>> from any BOGUS AGREEMENTS on behalf of your employer.
>>
>>
>>
>>      


-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (?BOGUS AGREEMENTS?) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.



From steve at holdenweb.com  Mon Aug  2 20:59:53 2010
From: steve at holdenweb.com (Steve Holden)
Date: Mon, 02 Aug 2010 14:59:53 -0400
Subject: [Python-Dev] No response to posts
In-Reply-To: <4C56FDE5.8050504@voidspace.org.uk>
References: <i32g9g$ouf$1@dough.gmane.org>	<4C54C5A4.6080409@netwok.org>	<AANLkTinpB7yVhMSQ=Q9hMCA+SnF4p+zNH98-GZd4ZP+w@mail.gmail.com>	<87r5ihm0k0.fsf@muni.brainbot.com>	<AANLkTikDM0nCVT1S9Jg-ZySTnysBvK0qk0Jpta8WZG82@mail.gmail.com>
	<4C56FDE5.8050504@voidspace.org.uk>
Message-ID: <4C5715A9.7070707@holdenweb.com>

On 8/2/2010 1:18 PM, Michael Foord wrote:
> On 02/08/2010 17:54, Brian Curtin wrote:
>> On Mon, Aug 2, 2010 at 11:39, Ralf Schmitt <ralf at brainbot.com
>> <mailto:ralf at brainbot.com>> wrote:
>>
>>     Benjamin Peterson <benjamin at python.org
>>     <mailto:benjamin at python.org>> writes:
>>
>>     > Please, let's stop messing with the tracker for everything. I think
>>     > the current set up works reasonably well, and we should focus on the
>>     > real problem: manpower
>>
>>     Ignoring issues (probably even with some patches attached) will drive
>>     contributors away. That's not the way to increase manpower.
>>
>>     - Ralf
>>
>>
>> Overall the "no response" query just passes the buck. Let's say we get
>> that query down to zero issues. What does that give us? Now we have
>> 500 issues with 2 responses. Sure, it makes further correspondence
>> more likely, but it's not solving any real issues and making any
>> measurably significant impact.
>>
> 
> Sure it could make a difference. People who submit issues will
> appreciate *some* response a great deal more than no response. More than
> that, if we have people dedicated to looking at new issues then we are
> more likely to *resolve* some that would otherwise "slip through the net".
> 
> 
>> While I do think the "no response" query can be helpful, let's not
>> attribute too much value to tiny tweaks of the tracker and reporting.
>> Benjamin is right -- manpower is where we'll benefit the most, not in
>> the manner we paint the current issue situation.
> 
> Sure. *Part* of drawing in more manpower can be engaging with those
> submitting issues and seeing if we can get them to post patches and / or
> tests - and suck them as far into Python development as we possibly can.
> ;-) For many people submitting an issue may be their first contact with
> Python developers and the Python development process (just as for others
> posting to Python-dev will be their first contact - even if they really
> should be posting to comp.lang.python instead).
> 

I agree with Michael that response to first issue posting is an
important potential recruitment channel.

It's important, though, that the response is friendly and encouraging
(not that there's anyone on this list who doesn't have those two
characteristics :-). And certainly not automated - that wouldn't help at
all.

regards
 Steve
-- 
Steve Holden           +1 571 484 6266   +1 800 494 3119
DjangoCon US September 7-9, 2010    http://djangocon.us/
See Python Video!       http://python.mirocommunity.org/
Holden Web LLC                 http://www.holdenweb.com/

From steve at holdenweb.com  Mon Aug  2 20:59:53 2010
From: steve at holdenweb.com (Steve Holden)
Date: Mon, 02 Aug 2010 14:59:53 -0400
Subject: [Python-Dev] No response to posts
In-Reply-To: <4C56FDE5.8050504@voidspace.org.uk>
References: <i32g9g$ouf$1@dough.gmane.org>	<4C54C5A4.6080409@netwok.org>	<AANLkTinpB7yVhMSQ=Q9hMCA+SnF4p+zNH98-GZd4ZP+w@mail.gmail.com>	<87r5ihm0k0.fsf@muni.brainbot.com>	<AANLkTikDM0nCVT1S9Jg-ZySTnysBvK0qk0Jpta8WZG82@mail.gmail.com>
	<4C56FDE5.8050504@voidspace.org.uk>
Message-ID: <4C5715A9.7070707@holdenweb.com>

On 8/2/2010 1:18 PM, Michael Foord wrote:
> On 02/08/2010 17:54, Brian Curtin wrote:
>> On Mon, Aug 2, 2010 at 11:39, Ralf Schmitt <ralf at brainbot.com
>> <mailto:ralf at brainbot.com>> wrote:
>>
>>     Benjamin Peterson <benjamin at python.org
>>     <mailto:benjamin at python.org>> writes:
>>
>>     > Please, let's stop messing with the tracker for everything. I think
>>     > the current set up works reasonably well, and we should focus on the
>>     > real problem: manpower
>>
>>     Ignoring issues (probably even with some patches attached) will drive
>>     contributors away. That's not the way to increase manpower.
>>
>>     - Ralf
>>
>>
>> Overall the "no response" query just passes the buck. Let's say we get
>> that query down to zero issues. What does that give us? Now we have
>> 500 issues with 2 responses. Sure, it makes further correspondence
>> more likely, but it's not solving any real issues and making any
>> measurably significant impact.
>>
> 
> Sure it could make a difference. People who submit issues will
> appreciate *some* response a great deal more than no response. More than
> that, if we have people dedicated to looking at new issues then we are
> more likely to *resolve* some that would otherwise "slip through the net".
> 
> 
>> While I do think the "no response" query can be helpful, let's not
>> attribute too much value to tiny tweaks of the tracker and reporting.
>> Benjamin is right -- manpower is where we'll benefit the most, not in
>> the manner we paint the current issue situation.
> 
> Sure. *Part* of drawing in more manpower can be engaging with those
> submitting issues and seeing if we can get them to post patches and / or
> tests - and suck them as far into Python development as we possibly can.
> ;-) For many people submitting an issue may be their first contact with
> Python developers and the Python development process (just as for others
> posting to Python-dev will be their first contact - even if they really
> should be posting to comp.lang.python instead).
> 

I agree with Michael that response to first issue posting is an
important potential recruitment channel.

It's important, though, that the response is friendly and encouraging
(not that there's anyone on this list who doesn't have those two
characteristics :-). And certainly not automated - that wouldn't help at
all.

regards
 Steve
-- 
Steve Holden           +1 571 484 6266   +1 800 494 3119
DjangoCon US September 7-9, 2010    http://djangocon.us/
See Python Video!       http://python.mirocommunity.org/
Holden Web LLC                 http://www.holdenweb.com/


From holger.krekel at gmail.com  Mon Aug  2 21:01:31 2010
From: holger.krekel at gmail.com (Holger Krekel)
Date: Mon, 2 Aug 2010 21:01:31 +0200
Subject: [Python-Dev] PEP 376 proposed changes for basic plugins support
In-Reply-To: <4C5712FD.90500@voidspace.org.uk>
References: <AANLkTinyjMkF2n91zS+48n6B_gkp9szW_bH0XJgTDh7D@mail.gmail.com> 
	<AANLkTi=n3gR=pDb90Es0h+jHL72jcU8g-TX3fPKLnXZY@mail.gmail.com> 
	<AANLkTi=SudSNzBK9UvM7wh+cwEwuxP6Y78CDFLqcaCez@mail.gmail.com> 
	<4C570A8A.1000508@voidspace.org.uk>
	<AANLkTinct3KsV5iyBBYXcp7HWqe2ZEDCYPjQauPOrXi3@mail.gmail.com> 
	<4C5712FD.90500@voidspace.org.uk>
Message-ID: <AANLkTimyeOkQjCyYJqs6qZbE1htZi+JDT-B1o_hO602U@mail.gmail.com>

On Mon, Aug 2, 2010 at 8:48 PM, Michael Foord <fuzzyman at voidspace.org.uk> wrote:
> On 02/08/2010 19:45, Holger Krekel wrote:
[...]
>>>> I'd much prefer a one-step process and rather provide a way to not-use
>>>> a plugin even if installed. ?The difference is e.g. with py.test that i
>>>> can point users to e.g.
>>>>
>>>> ? pip install pytest-figleaf
>>>> ? py.test --figleaf
>>>
>>> How do you achieve this currently?
>>>
>>
>> it uses setuptools entrypoints, so with a setup.py param like
>
> Right. I can't use that for unittest. With the new proposal we *could*
> automatically use all available plugins, but I think I prefer to only have
> plugins active that the user has chosen.

This sounds like a situation where a user has more installed
than he actually asked for.  I guess i am a big fan of "use virtualenv,
avoid global installations" and thus don't see the point to have
more installed than needed.

best,
holger

From mal at egenix.com  Mon Aug  2 21:36:34 2010
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon, 02 Aug 2010 21:36:34 +0200
Subject: [Python-Dev] PEP 376 proposed changes for basic plugins support
In-Reply-To: <4C56C57C.4000800@voidspace.org.uk>
References: <AANLkTinyjMkF2n91zS+48n6B_gkp9szW_bH0XJgTDh7D@mail.gmail.com>	<4C55FF0F.3010702@voidspace.org.uk>	<AANLkTim1af-zWEYF4U-vTr6d+8HkqFCycMVmQYsqpDcN@mail.gmail.com>	<4C5609A3.3090008@voidspace.org.uk>	<AANLkTimU-OUh8fzFoRvHMsQOqVa+jsFTfPyZKeY=heVg@mail.gmail.com>	<20100802010616.5FD133A4758@sparrow.telecommunity.com>	<AANLkTi=UDktBHXeQTU6_ouPk2sfnmhztMLY9yjzZJHP7@mail.gmail.com>	<4C56B846.9090009@egenix.com>	<20100802123145.2305.1286368223.divmod.xquotient.3@localhost.localdomain>
	<4C56C57C.4000800@voidspace.org.uk>
Message-ID: <4C571E42.9040408@egenix.com>

Michael Foord wrote:
> On 02/08/2010 13:31, exarkun at twistedmatrix.com wrote:
>> On 12:21 pm, mal at egenix.com wrote:
>>> Tarek Ziad? wrote:
>>>> On Mon, Aug 2, 2010 at 3:06 AM, P.J. Eby <pje at telecommunity.com> wrote:
>>>> ..
>>>>>
>>>>> So without specific examples of why this is a problem, it's hard to
>>>>> see why
>>>>> a special Python-specific set of configuration files is needed to
>>>>> resolve
>>>>> it, vs. say, encouraging application authors to use the available
>>>>> alternatives for doing plugin directories, config files, etc.
>>>>
>>>> I don't have a specific example in mind, and I must admit that if an
>>>> application does the right thing
>>>> (provide the right configuration file), this activate feature is not
>>>> useful at all. So it seems to be a bad idea.
>>>>
>>>> I propose that we drop the PLUGINS file idea and we add a new metadata
>>>> field called Provides-Plugin
>>>> in PEP 345, which will contain the info I've described minus the state
>>>> field. This will allow us to expose
>>>> plugins at PyPI.
>>>>
>>>> IOW, have entry points like setuptools provides, but in a metadata
>>>> field instead of a entry_points.txt file.
>>>
>>> Do we really need to make Python packaging even more complicated by
>>> adding support for application-specific plugin mechanisms ?
>>>
>>> Packages can already work as application plugins by simply defining
>>> a plugins namespace package and then placing the plugin packages
>>> into that namespace.
>>>
>>> See Zope for an example of how well this simply mechanism works out in
>>> practice: it simply scans the "Products" namespace for sub-packages and
>>> then loads each sub-package it finds to have it register itself with
>>> Zope.
>>
>> This is also roughly how Twisted's plugin system works.  One drawback,
>> though, is that it means potentially executing a large amount of
>> Python in order to load plugins.  This can build up to a significant
>> performance issue as more and more plugins are installed.
>>
> 
> unittest will solve this problem by having plugins explicitly enabled in
> its own configuration system, and possibly managed through a separate
> tool like a plugins subcommand. The full package list will *only* need
> to be scanned when managing plugins, not during normal execution.
> 
> Having this distutils2 supported "plugin declaration and discovery" will
> be extremely useful for the unittest plugin system. Given that plugins
> may need configuring after installation, and tools that handle both
> activation and configuration can be provided, it doesn't seem a heavy cost.
> 
> The downside to this is that installing and activating plugins are two
> separate steps. Given that each project can have a different set of
> plugins enabled I don't see a way round it.

You might want to take a look at the Trac plugin system which
works in more or less the same way:

http://trac.edgewall.org/wiki/TracPlugins


Since applications tend to have a rather diverse set of needs for
plugins, I don't think we should add plugins support to PEP 376.

Users of applications will not want to edit a single configuration
file to maintain plugins of many different applications (they might
break some other application doing so) and sys admins
will have trouble with such a setup as well (they usually want to
have control over which plugins get used for various reasons).

In the end, you'd have a system wide plugin configuration (maintained
by the sys admin), a per user one (with local customizations) and a
per application one (providing application-specific defaults) -
which only increases complexity and doesn't really solve anything.

Instead, I'd suggest to let each application do its own little thing
to manage plugins, in a complex or simple way, with or without
configuration, and have them all live happily side-by-side.

The stdlib should really only provide tools to applications and
make useful suggestions, not try to enforce application design
choices. I think that's simply out of scope for the stdlib

Tarek:

What you might want to do is add new type fields to PEP 345,
making it easier to identify and list packages that work as
plugins for applications, e.g.

Type: Plugin for MyCoolApp

The MyCoolApp could then use the Type-field to identify all
installed plugins, get their installation directories, etc.
and work on from there.

Whether or not to use an installed plugin is really not
without the scope of Python's packaging system. This is
something the application must provide in its config file,
together with possible additional sections to configure
a particular plugin.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Aug 02 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/
________________________________________________________________________

::: 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/

From martin at v.loewis.de  Mon Aug  2 21:40:42 2010
From: martin at v.loewis.de (=?windows-1252?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 02 Aug 2010 21:40:42 +0200
Subject: [Python-Dev] No response to posts
In-Reply-To: <4C56FDE5.8050504@voidspace.org.uk>
References: <i32g9g$ouf$1@dough.gmane.org>	<4C54C5A4.6080409@netwok.org>	<AANLkTinpB7yVhMSQ=Q9hMCA+SnF4p+zNH98-GZd4ZP+w@mail.gmail.com>	<87r5ihm0k0.fsf@muni.brainbot.com>	<AANLkTikDM0nCVT1S9Jg-ZySTnysBvK0qk0Jpta8WZG82@mail.gmail.com>
	<4C56FDE5.8050504@voidspace.org.uk>
Message-ID: <4C571F3A.5040102@v.loewis.de>

> Sure it could make a difference. People who submit issues will
> appreciate *some* response a great deal more than no response.

That depends. Sometimes, people post to the bug tracker to get help,
and they will get sad/driven away/angry when they get no response;
sometimes, if they get a response but no help, they will still get
sad/driven away/angry. Driving them away pointing out that the bug
tracker is not a place to obtain help might be as much help as "we"
can offer.

Other people post to the tracker to offer help. Those are the ones
that should not be driven away. Unfortunately, just responding to
them doesn't improve anything, IMO. If people only post to the issue
without any plan of actually doing something about the issue likely
still drives people away.

> Sure. *Part* of drawing in more manpower can be engaging with those
> submitting issues and seeing if we can get them to post patches and / or
> tests - and suck them as far into Python development as we possibly can.
> ;-) 

I think it's important to find out what people expect when posting
to the tracker. Maybe a mandatory radio list with these options
would help:

- I post this to get help from you
- I'm willing to work on other issues to expedite processing of this one
- The issue is not urgent, take your time

Regards,
Martin

From mail at timgolden.me.uk  Mon Aug  2 21:50:25 2010
From: mail at timgolden.me.uk (Tim Golden)
Date: Mon, 02 Aug 2010 20:50:25 +0100
Subject: [Python-Dev] No response to posts
In-Reply-To: <4C571F3A.5040102@v.loewis.de>
References: <i32g9g$ouf$1@dough.gmane.org>	<4C54C5A4.6080409@netwok.org>	<AANLkTinpB7yVhMSQ=Q9hMCA+SnF4p+zNH98-GZd4ZP+w@mail.gmail.com>	<87r5ihm0k0.fsf@muni.brainbot.com>	<AANLkTikDM0nCVT1S9Jg-ZySTnysBvK0qk0Jpta8WZG82@mail.gmail.com>	<4C56FDE5.8050504@voidspace.org.uk>
	<4C571F3A.5040102@v.loewis.de>
Message-ID: <4C572181.7050208@timgolden.me.uk>

On 02/08/2010 8:40 PM, "Martin v. L?wis" wrote:
> I think it's important to find out what people expect when posting
> to the tracker. Maybe a mandatory radio list with these options
> would help:
>
> - I post this to get help from you
> - I'm willing to work on other issues to expedite processing of this one
> - The issue is not urgent, take your time

Or, clearly in some cases:

- I'm just letting you know and walking away; I'm not particularly
interested in pursuing it any further as I've already worked around it.

TJG

From fuzzyman at voidspace.org.uk  Mon Aug  2 22:03:11 2010
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Mon, 02 Aug 2010 21:03:11 +0100
Subject: [Python-Dev] PEP 376 proposed changes for basic plugins support
In-Reply-To: <4C571E42.9040408@egenix.com>
References: <AANLkTinyjMkF2n91zS+48n6B_gkp9szW_bH0XJgTDh7D@mail.gmail.com>	<4C55FF0F.3010702@voidspace.org.uk>	<AANLkTim1af-zWEYF4U-vTr6d+8HkqFCycMVmQYsqpDcN@mail.gmail.com>	<4C5609A3.3090008@voidspace.org.uk>	<AANLkTimU-OUh8fzFoRvHMsQOqVa+jsFTfPyZKeY=heVg@mail.gmail.com>	<20100802010616.5FD133A4758@sparrow.telecommunity.com>	<AANLkTi=UDktBHXeQTU6_ouPk2sfnmhztMLY9yjzZJHP7@mail.gmail.com>	<4C56B846.9090009@egenix.com>	<20100802123145.2305.1286368223.divmod.xquotient.3@localhost.localdomain>
	<4C56C57C.4000800@voidspace.org.uk> <4C571E42.9040408@egenix.com>
Message-ID: <4C57247F.5060105@voidspace.org.uk>

On 02/08/2010 20:36, M.-A. Lemburg wrote:
> Michael Foord wrote:
>    
>> On 02/08/2010 13:31, exarkun at twistedmatrix.com wrote:
>>      
>>> On 12:21 pm, mal at egenix.com wrote:
>>>        
>>>> Tarek Ziad? wrote:
>>>>          
>>>>> On Mon, Aug 2, 2010 at 3:06 AM, P.J. Eby<pje at telecommunity.com>  wrote:
>>>>> ..
>>>>>            
>>>>>> So without specific examples of why this is a problem, it's hard to
>>>>>> see why
>>>>>> a special Python-specific set of configuration files is needed to
>>>>>> resolve
>>>>>> it, vs. say, encouraging application authors to use the available
>>>>>> alternatives for doing plugin directories, config files, etc.
>>>>>>              
>>>>> I don't have a specific example in mind, and I must admit that if an
>>>>> application does the right thing
>>>>> (provide the right configuration file), this activate feature is not
>>>>> useful at all. So it seems to be a bad idea.
>>>>>
>>>>> I propose that we drop the PLUGINS file idea and we add a new metadata
>>>>> field called Provides-Plugin
>>>>> in PEP 345, which will contain the info I've described minus the state
>>>>> field. This will allow us to expose
>>>>> plugins at PyPI.
>>>>>
>>>>> IOW, have entry points like setuptools provides, but in a metadata
>>>>> field instead of a entry_points.txt file.
>>>>>            
>>>> Do we really need to make Python packaging even more complicated by
>>>> adding support for application-specific plugin mechanisms ?
>>>>
>>>> Packages can already work as application plugins by simply defining
>>>> a plugins namespace package and then placing the plugin packages
>>>> into that namespace.
>>>>
>>>> See Zope for an example of how well this simply mechanism works out in
>>>> practice: it simply scans the "Products" namespace for sub-packages and
>>>> then loads each sub-package it finds to have it register itself with
>>>> Zope.
>>>>          
>>> This is also roughly how Twisted's plugin system works.  One drawback,
>>> though, is that it means potentially executing a large amount of
>>> Python in order to load plugins.  This can build up to a significant
>>> performance issue as more and more plugins are installed.
>>>
>>>        
>> unittest will solve this problem by having plugins explicitly enabled in
>> its own configuration system, and possibly managed through a separate
>> tool like a plugins subcommand. The full package list will *only* need
>> to be scanned when managing plugins, not during normal execution.
>>
>> Having this distutils2 supported "plugin declaration and discovery" will
>> be extremely useful for the unittest plugin system. Given that plugins
>> may need configuring after installation, and tools that handle both
>> activation and configuration can be provided, it doesn't seem a heavy cost.
>>
>> The downside to this is that installing and activating plugins are two
>> separate steps. Given that each project can have a different set of
>> plugins enabled I don't see a way round it.
>>      
> You might want to take a look at the Trac plugin system which
> works in more or less the same way:
>
> http://trac.edgewall.org/wiki/TracPlugins
>
>
>    

Ouch. I really don't want to emulate that system. For installing a 
plugin for a single project the recommended technique is:

     * Unpack the source. It should provide a setup.py.
     * Run:

       $ python setup.py bdist_egg

     Then you will have a *.egg file. Examine the output of running 
python to find where this was created.

     Once you have the plugin archive, you need to copy it into the 
plugins directory of the project environment

For global plugins it just uses entry points, which is similar to the 
functionality we are suggesting adding... However note:

     Unlike plugins installed per-environment, you'll have to explicitly 
enable globally installed plugins via trac.ini.

Really this sounds *astonishingly* like the system we are proposing. :-) 
(Global discovery with per-application choice about whether or not 
installed plugins are actually used).

> Since applications tend to have a rather diverse set of needs for
> plugins, I don't think we should add plugins support to PEP 376.
>    

We are really just suggesting adding entry points.
> Users of applications will not want to edit a single configuration
> file to maintain plugins of many different applications

This we are not proposing. Nor were we ever proposing it. The single 
file that was proposed (and in my understanding is no longer proposed) 
was to be maintained by distutils2 *anyway*.

> (they might
> break some other application doing so) and sys admins
> will have trouble with such a setup as well (they usually want to
> have control over which plugins get used for various reasons).
>
> In the end, you'd have a system wide plugin configuration (maintained
> by the sys admin), a per user one (with local customizations) and a
> per application one (providing application-specific defaults) -
> which only increases complexity and doesn't really solve anything.
>
>    

We simply provide information about the availability of plugins. System 
administrators or users can control the use of this information (and the 
plugins) as per their own policies.

> Instead, I'd suggest to let each application do its own little thing
> to manage plugins, in a complex or simple way, with or without
> configuration, and have them all live happily side-by-side.
>
> The stdlib should really only provide tools to applications and
> make useful suggestions, not try to enforce application design
> choices. I think that's simply out of scope for the stdlib
>
>    
Well, a tool for application developers is pretty much all that is being 
proposed.

All the best,

Michael Foord

> Tarek:
>
> What you might want to do is add new type fields to PEP 345,
> making it easier to identify and list packages that work as
> plugins for applications, e.g.
>
> Type: Plugin for MyCoolApp
>
> The MyCoolApp could then use the Type-field to identify all
> installed plugins, get their installation directories, etc.
> and work on from there.
>
> Whether or not to use an installed plugin is really not
> without the scope of Python's packaging system. This is
> something the application must provide in its config file,
> together with possible additional sections to configure
> a particular plugin.
>
>    


-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (?BOGUS AGREEMENTS?) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.



From mal at egenix.com  Mon Aug  2 22:37:39 2010
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon, 02 Aug 2010 22:37:39 +0200
Subject: [Python-Dev] PEP 376 proposed changes for basic plugins support
In-Reply-To: <4C57247F.5060105@voidspace.org.uk>
References: <AANLkTinyjMkF2n91zS+48n6B_gkp9szW_bH0XJgTDh7D@mail.gmail.com>	<4C55FF0F.3010702@voidspace.org.uk>	<AANLkTim1af-zWEYF4U-vTr6d+8HkqFCycMVmQYsqpDcN@mail.gmail.com>	<4C5609A3.3090008@voidspace.org.uk>	<AANLkTimU-OUh8fzFoRvHMsQOqVa+jsFTfPyZKeY=heVg@mail.gmail.com>	<20100802010616.5FD133A4758@sparrow.telecommunity.com>	<AANLkTi=UDktBHXeQTU6_ouPk2sfnmhztMLY9yjzZJHP7@mail.gmail.com>	<4C56B846.9090009@egenix.com>	<20100802123145.2305.1286368223.divmod.xquotient.3@localhost.localdomain>	<4C56C57C.4000800@voidspace.org.uk>
	<4C571E42.9040408@egenix.com> <4C57247F.5060105@voidspace.org.uk>
Message-ID: <4C572C93.4040207@egenix.com>

Michael Foord wrote:
> On 02/08/2010 20:36, M.-A. Lemburg wrote:
>> Michael Foord wrote:
>>   
>>> On 02/08/2010 13:31, exarkun at twistedmatrix.com wrote:
>>>     
>>>> On 12:21 pm, mal at egenix.com wrote:
>>>>       
>>>>> Tarek Ziad? wrote:
>>>>>         
>>>>>> On Mon, Aug 2, 2010 at 3:06 AM, P.J. Eby<pje at telecommunity.com> 
>>>>>> wrote:
>>>>>> ..
>>>>>>           
>>>>>>> So without specific examples of why this is a problem, it's hard to
>>>>>>> see why
>>>>>>> a special Python-specific set of configuration files is needed to
>>>>>>> resolve
>>>>>>> it, vs. say, encouraging application authors to use the available
>>>>>>> alternatives for doing plugin directories, config files, etc.
>>>>>>>              
>>>>>> I don't have a specific example in mind, and I must admit that if an
>>>>>> application does the right thing
>>>>>> (provide the right configuration file), this activate feature is not
>>>>>> useful at all. So it seems to be a bad idea.
>>>>>>
>>>>>> I propose that we drop the PLUGINS file idea and we add a new
>>>>>> metadata
>>>>>> field called Provides-Plugin
>>>>>> in PEP 345, which will contain the info I've described minus the
>>>>>> state
>>>>>> field. This will allow us to expose
>>>>>> plugins at PyPI.
>>>>>>
>>>>>> IOW, have entry points like setuptools provides, but in a metadata
>>>>>> field instead of a entry_points.txt file.
>>>>>>            
>>>>> Do we really need to make Python packaging even more complicated by
>>>>> adding support for application-specific plugin mechanisms ?
>>>>>
>>>>> Packages can already work as application plugins by simply defining
>>>>> a plugins namespace package and then placing the plugin packages
>>>>> into that namespace.
>>>>>
>>>>> See Zope for an example of how well this simply mechanism works out in
>>>>> practice: it simply scans the "Products" namespace for sub-packages
>>>>> and
>>>>> then loads each sub-package it finds to have it register itself with
>>>>> Zope.
>>>>>          
>>>> This is also roughly how Twisted's plugin system works.  One drawback,
>>>> though, is that it means potentially executing a large amount of
>>>> Python in order to load plugins.  This can build up to a significant
>>>> performance issue as more and more plugins are installed.
>>>>
>>>>        
>>> unittest will solve this problem by having plugins explicitly enabled in
>>> its own configuration system, and possibly managed through a separate
>>> tool like a plugins subcommand. The full package list will *only* need
>>> to be scanned when managing plugins, not during normal execution.
>>>
>>> Having this distutils2 supported "plugin declaration and discovery" will
>>> be extremely useful for the unittest plugin system. Given that plugins
>>> may need configuring after installation, and tools that handle both
>>> activation and configuration can be provided, it doesn't seem a heavy
>>> cost.
>>>
>>> The downside to this is that installing and activating plugins are two
>>> separate steps. Given that each project can have a different set of
>>> plugins enabled I don't see a way round it.
>>>      
>> You might want to take a look at the Trac plugin system which
>> works in more or less the same way:
>>
>> http://trac.edgewall.org/wiki/TracPlugins
>>
>>
>>    
> 
> Ouch. I really don't want to emulate that system. For installing a
> plugin for a single project the recommended technique is:
> 
>     * Unpack the source. It should provide a setup.py.
>     * Run:
> 
>       $ python setup.py bdist_egg
> 
>     Then you will have a *.egg file. Examine the output of running
> python to find where this was created.
> 
>     Once you have the plugin archive, you need to copy it into the
> plugins directory of the project environment
> 
> For global plugins it just uses entry points, which is similar to the
> functionality we are suggesting adding... However note:
> 
>     Unlike plugins installed per-environment, you'll have to explicitly
> enable globally installed plugins via trac.ini.
> 
> Really this sounds *astonishingly* like the system we are proposing. :-)
> (Global discovery with per-application choice about whether or not
> installed plugins are actually used).

The difference being that Trac is usually hosted using a
separate Python installation, so the pre-application choice is
really a per-Trac instance choice.

But yes, the system you are proposing does sound a lot like
what Trac uses and it works well - for that one application.

>> Since applications tend to have a rather diverse set of needs for
>> plugins, I don't think we should add plugins support to PEP 376.
> 
> We are really just suggesting adding entry points.

Tarek's email sounded a lot like the attempt to come up
with a universal plugin system, both in terms of managing
installed plugins and their configuration.

Perhaps I've just missed some twist in the thread :-)

>> Users of applications will not want to edit a single configuration
>> file to maintain plugins of many different applications
> 
> This we are not proposing. Nor were we ever proposing it. The single
> file that was proposed (and in my understanding is no longer proposed)
> was to be maintained by distutils2 *anyway*.

Sorry, I was refering to the plugins.cfg file used for
enabling the plugins, not the PLUGINS file used by
installers.

http://mail.python.org/pipermail/python-dev/2010-August/102627.html

>> (they might
>> break some other application doing so) and sys admins
>> will have trouble with such a setup as well (they usually want to
>> have control over which plugins get used for various reasons).
>>
>> In the end, you'd have a system wide plugin configuration (maintained
>> by the sys admin), a per user one (with local customizations) and a
>> per application one (providing application-specific defaults) -
>> which only increases complexity and doesn't really solve anything.
> 
> We simply provide information about the availability of plugins. System
> administrators or users can control the use of this information (and the
> plugins) as per their own policies.
> 
>> Instead, I'd suggest to let each application do its own little thing
>> to manage plugins, in a complex or simple way, with or without
>> configuration, and have them all live happily side-by-side.
>>
>> The stdlib should really only provide tools to applications and
>> make useful suggestions, not try to enforce application design
>> choices. I think that's simply out of scope for the stdlib
>>
>>    
> Well, a tool for application developers is pretty much all that is being
> proposed.

Right, but one which has consequences for users of applications
relying on the feature.

setuptools was also "just" a tool for application developers,
but one which had some serious side-effects for users.

Let's please not play the same trick again and be more careful
about the user side of things, e.g. plugin configuration should
not be part of a Python packaging system.

Plugin discovery is useful, but doesn't really require yet another
lookup file. The few bits of extra information could easily be
placed into the distribution meta-data of PEP 345.

Perhaps the main motivation behind adding a new PLUGINS file is to
reduce the overhead of having to scan dozens of meta-data .dist-info
directories ?!

If that's the case, then it would be better to come up with an
idea of how to make access to that meta-data available in a less
I/O intense way, e.g. by having pip or other package managers update
a central SQLite database cache of the data found on disk.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Aug 02 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/
________________________________________________________________________

::: 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/

From pje at telecommunity.com  Mon Aug  2 23:02:11 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Mon, 02 Aug 2010 17:02:11 -0400
Subject: [Python-Dev] PEP 376 proposed changes for basic plugins support
Message-ID: <20100802210209.9C7BF3A4783@sparrow.telecommunity.com>

At 05:08 PM 8/2/2010 +0200, ??ric Araujo wrote:
>I wonder if functions in pkgutil or importlib could allow one to 
>iterate over the plugins (i.e. submodules and subpackages of the 
>namespace package) without actually loading then.

See pkgutil.walk_packages(), available since 2.5.

It has to load __init__.py files, especially because of namespace 
packages, but it doesn't load any non-package modules.

That being said, using namespace packages for plugins kind of defeats 
the true purpose of namespace packages, which is to give developers 
private package namespaces they can use across multiple projects, 
like zope.*, peak.*, twisted.*, etc., thereby avoiding naming 
conflicts in the root package namespace.

Granted, you can always re-nest namespaces and do something like 
someproject.plugins.mynamehere.myplugin, but with entry points you 
can just register something in mynamehere.mysomeprojectplugin, and 
flat is better than nested.  ;-)  (Plus, you can include information 
about the individual plugins/features residing in that module in the 
metadata, and avoid importing until/unless you need that feature.)


From pje at telecommunity.com  Mon Aug  2 23:15:29 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Mon, 02 Aug 2010 17:15:29 -0400
Subject: [Python-Dev] PEP 376 proposed changes for basic plugins support
In-Reply-To: <4C57247F.5060105@voidspace.org.uk>
References: <AANLkTinyjMkF2n91zS+48n6B_gkp9szW_bH0XJgTDh7D@mail.gmail.com>
	<4C55FF0F.3010702@voidspace.org.uk>
	<AANLkTim1af-zWEYF4U-vTr6d+8HkqFCycMVmQYsqpDcN@mail.gmail.com>
	<4C5609A3.3090008@voidspace.org.uk>
	<AANLkTimU-OUh8fzFoRvHMsQOqVa+jsFTfPyZKeY=heVg@mail.gmail.com>
	<20100802010616.5FD133A4758@sparrow.telecommunity.com>
	<AANLkTi=UDktBHXeQTU6_ouPk2sfnmhztMLY9yjzZJHP7@mail.gmail.com>
	<4C56B846.9090009@egenix.com>
	<20100802123145.2305.1286368223.divmod.xquotient.3@localhost.localdomain>
	<4C56C57C.4000800@voidspace.org.uk> <4C571E42.9040408@egenix.com>
	<4C57247F.5060105@voidspace.org.uk>
Message-ID: <20100802211526.D8A443A4783@sparrow.telecommunity.com>

At 09:03 PM 8/2/2010 +0100, Michael Foord wrote:
>Ouch. I really don't want to emulate that system. For installing a
>plugin for a single project the recommended technique is:
>
>      * Unpack the source. It should provide a setup.py.
>      * Run:
>
>        $ python setup.py bdist_egg
>
>      Then you will have a *.egg file. Examine the output of running
>python to find where this was created.
>
>      Once you have the plugin archive, you need to copy it into the
>plugins directory of the project environment

Those instructions are apparently out-of-date; you can actually just 
"easy_install -m" or "pip" the plugin directly to the plugins 
directory, without any additional intervening steps.

(The only reason to create an .egg file for Trac is if you intend to 
distribute to non-developer users who will be told to just drop it in 
the plugins directory.)


>For global plugins it just uses entry points, which is similar to the
>functionality we are suggesting adding...

I believe it's using entry points for both, actually.  It just has an 
(application-specific) filtering mechanism to restrict which entry 
points get loaded.


>Really this sounds *astonishingly* like the system we are proposing. :-)

Which is why I keep pointing out that the code for doing most of it 
is already available in setuptools, distribute, pip, buildout, etc., 
and so (IMO) ought to just get copied into distutils2, the way 
easy_install's package index code was.  ;-)

(Of course, adding some filtering utilities to make it easier for 
apps to do explicit configuration would still be nice.)


From benjamin at python.org  Mon Aug  2 23:18:59 2010
From: benjamin at python.org (Benjamin Peterson)
Date: Mon, 2 Aug 2010 16:18:59 -0500
Subject: [Python-Dev] No response to posts
In-Reply-To: <i372n8$2mg$1@dough.gmane.org>
References: <i32g9g$ouf$1@dough.gmane.org> <4C54C5A4.6080409@netwok.org>
	<AANLkTinpB7yVhMSQ=Q9hMCA+SnF4p+zNH98-GZd4ZP+w@mail.gmail.com>
	<87r5ihm0k0.fsf@muni.brainbot.com>
	<AANLkTikDM0nCVT1S9Jg-ZySTnysBvK0qk0Jpta8WZG82@mail.gmail.com>
	<i372n8$2mg$1@dough.gmane.org>
Message-ID: <AANLkTinhe5xfO+sswME-HuKK_ecfrdrhaGhzKPXZFL-7@mail.gmail.com>

2010/8/2 Terry Reedy <tjreedy at udel.edu>:
> On 8/2/2010 12:54 PM, Brian Curtin wrote:
>>
>> On Mon, Aug 2, 2010 at 11:39, Ralf Schmitt <ralf at brainbot.com
>> <mailto:ralf at brainbot.com>> wrote:
>>
>> ? ?Benjamin Peterson <benjamin at python.org <mailto:benjamin at python.org>>
>> ? ?writes:
>>
>> ? ? > Please, let's stop messing with the tracker for everything. I think
>> ? ? > the current set up works reasonably well, and we should focus on the
>> ? ? > real problem: manpower
>
> Two months ago, I discovered and reported that about 1/5 of open issues had
> no responses. Is that 'reasonably well'?

I'm only referring to the infrastructure when I say "the current
setup." I don't think repeatedly tweaking the tracker is likely to
close more issues.



-- 
Regards,
Benjamin

From pje at telecommunity.com  Mon Aug  2 23:31:07 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Mon, 02 Aug 2010 17:31:07 -0400
Subject: [Python-Dev] PEP 376 proposed changes for basic plugins support
In-Reply-To: <4C572C93.4040207@egenix.com>
References: <AANLkTinyjMkF2n91zS+48n6B_gkp9szW_bH0XJgTDh7D@mail.gmail.com>
	<4C55FF0F.3010702@voidspace.org.uk>
	<AANLkTim1af-zWEYF4U-vTr6d+8HkqFCycMVmQYsqpDcN@mail.gmail.com>
	<4C5609A3.3090008@voidspace.org.uk>
	<AANLkTimU-OUh8fzFoRvHMsQOqVa+jsFTfPyZKeY=heVg@mail.gmail.com>
	<20100802010616.5FD133A4758@sparrow.telecommunity.com>
	<AANLkTi=UDktBHXeQTU6_ouPk2sfnmhztMLY9yjzZJHP7@mail.gmail.com>
	<4C56B846.9090009@egenix.com>
	<20100802123145.2305.1286368223.divmod.xquotient.3@localhost.localdomain>
	<4C56C57C.4000800@voidspace.org.uk> <4C571E42.9040408@egenix.com>
	<4C57247F.5060105@voidspace.org.uk> <4C572C93.4040207@egenix.com>
Message-ID: <20100802213104.E6EFC3A479B@sparrow.telecommunity.com>

At 10:37 PM 8/2/2010 +0200, M.-A. Lemburg wrote:
>If that's the case, then it would be better to come up with an
>idea of how to make access to that meta-data available in a less
>I/O intense way, e.g. by having pip or other package managers update
>a central SQLite database cache of the data found on disk.

Don't forget system packaging tools like .deb, .rpm, etc., which do 
not generally take kindly to updating such things.  For better or 
worse, the filesystem *is* our "central database" these days.

Btw, while adding PLUGINS to PEP 376 is a new proposal, it's 
essentially another spelling of the existing entry_points.txt used by 
eggs; it changes the format to csv instead of .ini, and adds 
"description" and "type" fields, but drops requirements information 
and I'm not sure if it can point to arbitrary objects the way 
entry_points.txt can.

Anyway, entry_points.txt has been around enough years in the field 
that the concept itself can't really be called "new" - it's actually 
quite proven.  Checking 
http://nullege.com/codes/search/pkg_resources.iter_entry_points/call 
, I find 187 modules using just that one entry points API.

Some projects do have more than one module loading plugins, but the 
majority of those 187 appear to be different projects.

Note that that's modules *loading plugins*, not plugins being 
provided...  so the total number of PyPI projects using entry points 
in some way is likely much higher, once you add in the plugins that 
these 187 lookups are, well, looking up.



From ncoghlan at gmail.com  Tue Aug  3 00:05:35 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 3 Aug 2010 08:05:35 +1000
Subject: [Python-Dev] No response to posts
In-Reply-To: <AANLkTinhe5xfO+sswME-HuKK_ecfrdrhaGhzKPXZFL-7@mail.gmail.com>
References: <i32g9g$ouf$1@dough.gmane.org> <4C54C5A4.6080409@netwok.org>
	<AANLkTinpB7yVhMSQ=Q9hMCA+SnF4p+zNH98-GZd4ZP+w@mail.gmail.com>
	<87r5ihm0k0.fsf@muni.brainbot.com>
	<AANLkTikDM0nCVT1S9Jg-ZySTnysBvK0qk0Jpta8WZG82@mail.gmail.com>
	<i372n8$2mg$1@dough.gmane.org>
	<AANLkTinhe5xfO+sswME-HuKK_ecfrdrhaGhzKPXZFL-7@mail.gmail.com>
Message-ID: <AANLkTik+sFUL11yeMFFrx5wB0yYWLF3nUNtwe3kGo_Mj@mail.gmail.com>

On Tue, Aug 3, 2010 at 7:18 AM, Benjamin Peterson <benjamin at python.org> wrote:
> I'm only referring to the infrastructure when I say "the current
> setup." I don't think repeatedly tweaking the tracker is likely to
> close more issues.

But tweaking the tracker to improve the way we *interact* with
potential contributors may get more developers in the long run, as
well as closing more issues. Currently, if a bug doesn't get responded
to immediately by people monitoring the bugs list, then there's no
easy way to go back and query "hey, are there any bugs nobody has even
looked at yet?". All this discussion is about is acknowledging that
that is something we should try to keep under control by listing them
in the weekly summary and by making them easy to look up.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From benjamin at python.org  Tue Aug  3 00:13:01 2010
From: benjamin at python.org (Benjamin Peterson)
Date: Mon, 2 Aug 2010 17:13:01 -0500
Subject: [Python-Dev] No response to posts
In-Reply-To: <AANLkTik+sFUL11yeMFFrx5wB0yYWLF3nUNtwe3kGo_Mj@mail.gmail.com>
References: <i32g9g$ouf$1@dough.gmane.org> <4C54C5A4.6080409@netwok.org>
	<AANLkTinpB7yVhMSQ=Q9hMCA+SnF4p+zNH98-GZd4ZP+w@mail.gmail.com>
	<87r5ihm0k0.fsf@muni.brainbot.com>
	<AANLkTikDM0nCVT1S9Jg-ZySTnysBvK0qk0Jpta8WZG82@mail.gmail.com>
	<i372n8$2mg$1@dough.gmane.org>
	<AANLkTinhe5xfO+sswME-HuKK_ecfrdrhaGhzKPXZFL-7@mail.gmail.com>
	<AANLkTik+sFUL11yeMFFrx5wB0yYWLF3nUNtwe3kGo_Mj@mail.gmail.com>
Message-ID: <AANLkTimr4EavemsRaWaYz53iyOpSutdb6hqcdfaNiv8A@mail.gmail.com>

2010/8/2 Nick Coghlan <ncoghlan at gmail.com>:
> On Tue, Aug 3, 2010 at 7:18 AM, Benjamin Peterson <benjamin at python.org> wrote:
>> I'm only referring to the infrastructure when I say "the current
>> setup." I don't think repeatedly tweaking the tracker is likely to
>> close more issues.
>
> But tweaking the tracker to improve the way we *interact* with
> potential contributors may get more developers in the long run, as
> well as closing more issues. Currently, if a bug doesn't get responded
> to immediately by people monitoring the bugs list, then there's no
> easy way to go back and query "hey, are there any bugs nobody has even
> looked at yet?". All this discussion is about is acknowledging that
> that is something we should try to keep under control by listing them
> in the weekly summary and by making them easy to look up.

Well, I just feel like we keep changing things to little result,
creating an organic mess of fields and statuses. Adding more queries
is fine, but let's not bow to the temptation to add more fields.


-- 
Regards,
Benjamin

From ncoghlan at gmail.com  Tue Aug  3 00:17:44 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 3 Aug 2010 08:17:44 +1000
Subject: [Python-Dev] Tracker status
Message-ID: <AANLkTi=fcQJP6SuNSz35+HpCzeDVY8bYEs2VtLS2Mq2z@mail.gmail.com>

Are the bug tracker and meta-tracker down for anyone else, or is it just me?

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From tjreedy at udel.edu  Tue Aug  3 00:25:11 2010
From: tjreedy at udel.edu (Terry Reedy)
Date: Mon, 02 Aug 2010 18:25:11 -0400
Subject: [Python-Dev] Tracker down
Message-ID: <i37gk5$lu2$1@dough.gmane.org>

6:22 EDT, tracker down and has been for a couple of minutes.
python.org and docs.python.org are fine.
Does the daemon program that now checks on Pypi also check the tracker?
Is there a particular place to report tracker down?
Or should I just assume someone else will notice and do something?

-- 
Terry Jan Reedy


From barry at python.org  Tue Aug  3 00:41:41 2010
From: barry at python.org (Barry Warsaw)
Date: Mon, 2 Aug 2010 18:41:41 -0400
Subject: [Python-Dev] Tracker down
In-Reply-To: <i37gk5$lu2$1@dough.gmane.org>
References: <i37gk5$lu2$1@dough.gmane.org>
Message-ID: <20100802184141.7e5b5cc3@limelight.wooz.org>

On Aug 02, 2010, at 06:25 PM, Terry Reedy wrote:

>6:22 EDT, tracker down and has been for a couple of minutes.
>python.org and docs.python.org are fine.
>Does the daemon program that now checks on Pypi also check the tracker?
>Is there a particular place to report tracker down?
>Or should I just assume someone else will notice and do something?

We've been talking about it on #python-dev and I've sent a message off to our
internal emergency list.  It's holding up the 2.6.6rc1 release.  (No, I do not
have access, nor can I answer your questions.)

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100802/30066123/attachment.pgp>

From solipsis at pitrou.net  Tue Aug  3 00:43:53 2010
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Tue, 3 Aug 2010 00:43:53 +0200
Subject: [Python-Dev] No response to posts
References: <i32g9g$ouf$1@dough.gmane.org> <4C54C5A4.6080409@netwok.org>
	<AANLkTinpB7yVhMSQ=Q9hMCA+SnF4p+zNH98-GZd4ZP+w@mail.gmail.com>
	<87r5ihm0k0.fsf@muni.brainbot.com>
	<AANLkTikDM0nCVT1S9Jg-ZySTnysBvK0qk0Jpta8WZG82@mail.gmail.com>
	<i372n8$2mg$1@dough.gmane.org>
	<AANLkTinhe5xfO+sswME-HuKK_ecfrdrhaGhzKPXZFL-7@mail.gmail.com>
	<AANLkTik+sFUL11yeMFFrx5wB0yYWLF3nUNtwe3kGo_Mj@mail.gmail.com>
	<AANLkTimr4EavemsRaWaYz53iyOpSutdb6hqcdfaNiv8A@mail.gmail.com>
Message-ID: <20100803004353.14607c91@pitrou.net>

On Mon, 2 Aug 2010 17:13:01 -0500
Benjamin Peterson <benjamin at python.org> wrote:

> 2010/8/2 Nick Coghlan <ncoghlan at gmail.com>:
> > On Tue, Aug 3, 2010 at 7:18 AM, Benjamin Peterson <benjamin at python.org> wrote:
> >> I'm only referring to the infrastructure when I say "the current
> >> setup." I don't think repeatedly tweaking the tracker is likely to
> >> close more issues.
> >
> > But tweaking the tracker to improve the way we *interact* with
> > potential contributors may get more developers in the long run, as
> > well as closing more issues. Currently, if a bug doesn't get responded
> > to immediately by people monitoring the bugs list, then there's no
> > easy way to go back and query "hey, are there any bugs nobody has even
> > looked at yet?". All this discussion is about is acknowledging that
> > that is something we should try to keep under control by listing them
> > in the weekly summary and by making them easy to look up.
> 
> Well, I just feel like we keep changing things to little result,
> creating an organic mess of fields and statuses. Adding more queries
> is fine, but let's not bow to the temptation to add more fields.

FWIW, I completely agree with Benjamin.

Regards

Antoine.



From barry at python.org  Tue Aug  3 00:45:14 2010
From: barry at python.org (Barry Warsaw)
Date: Mon, 2 Aug 2010 18:45:14 -0400
Subject: [Python-Dev] Is it intentional that "sys.__debug__ = 1" is
 illegal in Python 2.7?
In-Reply-To: <AANLkTinvU-QwqP6G2TPH-cROeUqUhDt3OsA1Ce61iwdy@mail.gmail.com>
References: <20100730162608.7315c3a5@heresy>
	<AANLkTinvU-QwqP6G2TPH-cROeUqUhDt3OsA1Ce61iwdy@mail.gmail.com>
Message-ID: <20100802184514.1b311fdc@limelight.wooz.org>

On Aug 01, 2010, at 09:56 PM, Benjamin Peterson wrote:

>2010/7/30 Barry Warsaw <barry at python.org>:
>>
>> It looks like Benjamin's change in r67171 was the relevant diff.
>
>The reason behind this was to make __debug__ assignment consistent
>with that of other reserved names. For example, x.None = 3 raised and
>thus, so should x.__debug__ = 3.

BTW, thanks to Georg for closing the documentation issue.
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100802/4c1a2595/attachment.pgp>

From merwok at netwok.org  Tue Aug  3 00:50:23 2010
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Tue, 03 Aug 2010 00:50:23 +0200
Subject: [Python-Dev] No response to posts
In-Reply-To: <AANLkTimr4EavemsRaWaYz53iyOpSutdb6hqcdfaNiv8A@mail.gmail.com>
References: <i32g9g$ouf$1@dough.gmane.org>
	<4C54C5A4.6080409@netwok.org>	<AANLkTinpB7yVhMSQ=Q9hMCA+SnF4p+zNH98-GZd4ZP+w@mail.gmail.com>	<87r5ihm0k0.fsf@muni.brainbot.com>	<AANLkTikDM0nCVT1S9Jg-ZySTnysBvK0qk0Jpta8WZG82@mail.gmail.com>	<i372n8$2mg$1@dough.gmane.org>	<AANLkTinhe5xfO+sswME-HuKK_ecfrdrhaGhzKPXZFL-7@mail.gmail.com>	<AANLkTik+sFUL11yeMFFrx5wB0yYWLF3nUNtwe3kGo_Mj@mail.gmail.com>
	<AANLkTimr4EavemsRaWaYz53iyOpSutdb6hqcdfaNiv8A@mail.gmail.com>
Message-ID: <4C574BAF.5040409@netwok.org>

> Well, I just feel like we keep changing things to little result,
> creating an organic mess of fields and statuses. Adding more queries
> is fine, but let's not bow to the temptation to add more fields.

AFAICT, Ezio certainly wants to solve the status/stage/resolution
unclear overlap, and in general making the UI better (this means
removing things).

Regards


From breamoreboy at yahoo.co.uk  Tue Aug  3 01:00:46 2010
From: breamoreboy at yahoo.co.uk (Mark Lawrence)
Date: Tue, 03 Aug 2010 00:00:46 +0100
Subject: [Python-Dev] No response to posts
In-Reply-To: <AANLkTinhe5xfO+sswME-HuKK_ecfrdrhaGhzKPXZFL-7@mail.gmail.com>
References: <i32g9g$ouf$1@dough.gmane.org>
	<4C54C5A4.6080409@netwok.org>	<AANLkTinpB7yVhMSQ=Q9hMCA+SnF4p+zNH98-GZd4ZP+w@mail.gmail.com>	<87r5ihm0k0.fsf@muni.brainbot.com>	<AANLkTikDM0nCVT1S9Jg-ZySTnysBvK0qk0Jpta8WZG82@mail.gmail.com>	<i372n8$2mg$1@dough.gmane.org>
	<AANLkTinhe5xfO+sswME-HuKK_ecfrdrhaGhzKPXZFL-7@mail.gmail.com>
Message-ID: <i37imv$rli$1@dough.gmane.org>

On 02/08/2010 22:18, Benjamin Peterson wrote:
> 2010/8/2 Terry Reedy<tjreedy at udel.edu>:
>> On 8/2/2010 12:54 PM, Brian Curtin wrote:
>>>
>>> On Mon, Aug 2, 2010 at 11:39, Ralf Schmitt<ralf at brainbot.com
>>> <mailto:ralf at brainbot.com>>  wrote:
>>>
>>>     Benjamin Peterson<benjamin at python.org<mailto:benjamin at python.org>>
>>>     writes:
>>>
>>>      >  Please, let's stop messing with the tracker for everything. I think
>>>      >  the current set up works reasonably well, and we should focus on the
>>>      >  real problem: manpower
>>
>> Two months ago, I discovered and reported that about 1/5 of open issues had
>> no responses. Is that 'reasonably well'?
>
> I'm only referring to the infrastructure when I say "the current
> setup." I don't think repeatedly tweaking the tracker is likely to
> close more issues.
>

I find this response quite pathetic.  The bulk of Terry's post has been 
snipped.  My own earlier response has been ignored.  Please Benjamin get 
out of your ivory tower, there are people such as myself who want to 
help, but we feel locked out.

Yes I am aware that I've more than trodden on a few toes as part of my 
learning curve, but all in all in I'm very proud of the fact that in my 
brief tenure I've helped the Python community.  The number of responses 
that I've had stating "Thanks I've forgotten that one" far out number 
the negative ones.  Actually I've never had any negative ones.  I guess 
that some of you are not as bold as I pretend to be.  Honestly by nature 
I'm very quiet and shy so when I start talking like this I'm being very 
serious and it's taken me years to get there.

Further, issues don't have to be closed, but what has to happen is that 
any issue that get raised *MUST* have a response.  This doesn't mean 
someone bumping the Python versions up five years after the issue was 
raised.

Fly back at me if you like.  I don't care about me.  I don't care about 
you.  I do care about Python.

Kindest regards.

Mark Lawrence.



From breamoreboy at yahoo.co.uk  Tue Aug  3 01:04:32 2010
From: breamoreboy at yahoo.co.uk (Mark Lawrence)
Date: Tue, 03 Aug 2010 00:04:32 +0100
Subject: [Python-Dev] No response to posts
In-Reply-To: <20100803004353.14607c91@pitrou.net>
References: <i32g9g$ouf$1@dough.gmane.org>
	<4C54C5A4.6080409@netwok.org>	<AANLkTinpB7yVhMSQ=Q9hMCA+SnF4p+zNH98-GZd4ZP+w@mail.gmail.com>	<87r5ihm0k0.fsf@muni.brainbot.com>	<AANLkTikDM0nCVT1S9Jg-ZySTnysBvK0qk0Jpta8WZG82@mail.gmail.com>	<i372n8$2mg$1@dough.gmane.org>	<AANLkTinhe5xfO+sswME-HuKK_ecfrdrhaGhzKPXZFL-7@mail.gmail.com>	<AANLkTik+sFUL11yeMFFrx5wB0yYWLF3nUNtwe3kGo_Mj@mail.gmail.com>	<AANLkTimr4EavemsRaWaYz53iyOpSutdb6hqcdfaNiv8A@mail.gmail.com>
	<20100803004353.14607c91@pitrou.net>
Message-ID: <i37iu1$rli$2@dough.gmane.org>

On 02/08/2010 23:43, Antoine Pitrou wrote:
> On Mon, 2 Aug 2010 17:13:01 -0500
> Benjamin Peterson<benjamin at python.org>  wrote:
>
>> 2010/8/2 Nick Coghlan<ncoghlan at gmail.com>:
>>> On Tue, Aug 3, 2010 at 7:18 AM, Benjamin Peterson<benjamin at python.org>  wrote:
>>>> I'm only referring to the infrastructure when I say "the current
>>>> setup." I don't think repeatedly tweaking the tracker is likely to
>>>> close more issues.
>>>
>>> But tweaking the tracker to improve the way we *interact* with
>>> potential contributors may get more developers in the long run, as
>>> well as closing more issues. Currently, if a bug doesn't get responded
>>> to immediately by people monitoring the bugs list, then there's no
>>> easy way to go back and query "hey, are there any bugs nobody has even
>>> looked at yet?". All this discussion is about is acknowledging that
>>> that is something we should try to keep under control by listing them
>>> in the weekly summary and by making them easy to look up.
>>
>> Well, I just feel like we keep changing things to little result,
>> creating an organic mess of fields and statuses. Adding more queries
>> is fine, but let's not bow to the temptation to add more fields.
>
> FWIW, I completely agree with Benjamin.
>
> Regards
>
> Antoine.
>
>

I completely disagree.

Please see my other post.

Kindest regards.

Mark Lawrence.


From merwok at netwok.org  Tue Aug  3 01:07:02 2010
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Tue, 03 Aug 2010 01:07:02 +0200
Subject: [Python-Dev] PEP 376 proposed changes for basic plugins support
In-Reply-To: <4C571E42.9040408@egenix.com>
References: <AANLkTinyjMkF2n91zS+48n6B_gkp9szW_bH0XJgTDh7D@mail.gmail.com>	<4C55FF0F.3010702@voidspace.org.uk>	<AANLkTim1af-zWEYF4U-vTr6d+8HkqFCycMVmQYsqpDcN@mail.gmail.com>	<4C5609A3.3090008@voidspace.org.uk>	<AANLkTimU-OUh8fzFoRvHMsQOqVa+jsFTfPyZKeY=heVg@mail.gmail.com>	<20100802010616.5FD133A4758@sparrow.telecommunity.com>	<AANLkTi=UDktBHXeQTU6_ouPk2sfnmhztMLY9yjzZJHP7@mail.gmail.com>	<4C56B846.9090009@egenix.com>	<20100802123145.2305.1286368223.divmod.xquotient.3@localhost.localdomain>	<4C56C57C.4000800@voidspace.org.uk>
	<4C571E42.9040408@egenix.com>
Message-ID: <4C574F96.9050200@netwok.org>

> What you might want to do is add new type fields to PEP 345,
> making it easier to identify and list packages that work as
> plugins for applications, e.g.
> 
> Type: Plugin for MyCoolApp
> 
> The MyCoolApp could then use the Type-field to identify all
> installed plugins, get their installation directories, etc.
> and work on from there.

Classifiers seem a good way to do that. They?re already defined in
accepted PEPs, extensible on demand, used by Web frameworks
components/applications/middlewares/things and other projects, and
queriable in PyPI.

We could use ?Environment :: Plugins? and ?Framework :: Something? or
define a new classifier (not all applications are frameworks, and
?plugins? seems a very strange value for ?environment?).

It would be the first time that a classifier triggers specific
processing from distutils though, so we may prefer to define a new
Provides-Plugin field for consistency and explicitness.

Regards


From db3l.net at gmail.com  Tue Aug  3 01:21:32 2010
From: db3l.net at gmail.com (David Bolen)
Date: Mon, 02 Aug 2010 19:21:32 -0400
Subject: [Python-Dev] proto-pep: plugin proposal (for unittest)
References: <f9203038-f94b-eb28-b9af-d3200dc27db9@me.com>
	<4C56CF81.20803@voidspace.org.uk>
Message-ID: <m262zsppmr.fsf@valheru.db3l.homeip.net>

Michael Foord <fuzzyman at voidspace.org.uk> writes:

> I would be interested in hearing from other Mac users as to where they
> would look for configuration files for command line tools - in ~ or in
> ~/Library/Preferences?

My primary personal machine has been OSX for years now, and as someone
who lives in the command line (well, or Emacs shells), I think either
approach is workable for command line only tools.

I will say that if I need to find preferences or application-specific
files my first inclination is absolutely to look under ~/Library.
That's the "platform" location (just as looking for dot files under
Linux is my first choice, or "Documents and Settings/<user>" for
Windows).  I don't think I shift mental gears automatically for
command line tools versus not, unless I have some prior knowledge
about the tool.

With that said, given all the third party and Unix-oriented stuff I
install under OSX, it's hardly rare (as has been pointed out
elsewhere) to be working with ~/.<something> either, so it's not like
I'd consider it that unusual to find that's where I need to go.

In glancing at my current system, it does appear command line only
tools are more commonly using ~/.<something> files rather than under
~/Library (which tends to be stuff packaged up as an application in
/Applications, even if they can also be run from the command line).

Though it might be a biased sample set since I'm more likely to have
brought in command line tools to OSX from the Unix side of things, I
suspect that's true of other users of command line tools as well.

I will say that it's rarer to find a native (Cocoa/Carbon) GUI
application that doesn't store preferences or application settings
beneath ~/Library, and in such a case I'd feel they were more "wrong"
and non-conforming if they didn't do that.  So it depends on how
"native" an application wishes to be perceived.  I guess in thinking
about it while writing this, having something installed in
/Applications is more strongly linked with ~/Library in my mind than
other tools.

Of course, even with /Applications, non-native GUI apps are more of a
mixed bag.  For example, the X versions of Gimp and Inkscape - Gimp
properly uses "~/Library/Application Support" while Inkscape still
uses ~/.inkscape.  Of course, as X apps, neither truly feels native or
conforming anyway.

So that probably helps make things as clear as mud :-)

-- David


From solipsis at pitrou.net  Tue Aug  3 01:24:24 2010
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Tue, 3 Aug 2010 01:24:24 +0200
Subject: [Python-Dev] No response to posts
References: <i32g9g$ouf$1@dough.gmane.org> <4C54C5A4.6080409@netwok.org>
	<AANLkTinpB7yVhMSQ=Q9hMCA+SnF4p+zNH98-GZd4ZP+w@mail.gmail.com>
	<87r5ihm0k0.fsf@muni.brainbot.com>
	<AANLkTikDM0nCVT1S9Jg-ZySTnysBvK0qk0Jpta8WZG82@mail.gmail.com>
	<i372n8$2mg$1@dough.gmane.org>
	<AANLkTinhe5xfO+sswME-HuKK_ecfrdrhaGhzKPXZFL-7@mail.gmail.com>
	<i37imv$rli$1@dough.gmane.org>
Message-ID: <20100803012424.48807800@pitrou.net>

On Tue, 03 Aug 2010 00:00:46 +0100
Mark Lawrence <breamoreboy at yahoo.co.uk> wrote:
> 
> Fly back at me if you like.  I don't care about me.  I don't care about 
> you.  I do care about Python.

Well, you should care about people. Free software is as much as about
building welcoming communities than it is about writing good software.

Regards

Antoine.



From breamoreboy at yahoo.co.uk  Tue Aug  3 01:39:41 2010
From: breamoreboy at yahoo.co.uk (Mark Lawrence)
Date: Tue, 03 Aug 2010 00:39:41 +0100
Subject: [Python-Dev] No response to posts
In-Reply-To: <20100803012424.48807800@pitrou.net>
References: <i32g9g$ouf$1@dough.gmane.org>
	<4C54C5A4.6080409@netwok.org>	<AANLkTinpB7yVhMSQ=Q9hMCA+SnF4p+zNH98-GZd4ZP+w@mail.gmail.com>	<87r5ihm0k0.fsf@muni.brainbot.com>	<AANLkTikDM0nCVT1S9Jg-ZySTnysBvK0qk0Jpta8WZG82@mail.gmail.com>	<i372n8$2mg$1@dough.gmane.org>	<AANLkTinhe5xfO+sswME-HuKK_ecfrdrhaGhzKPXZFL-7@mail.gmail.com>	<i37imv$rli$1@dough.gmane.org>
	<20100803012424.48807800@pitrou.net>
Message-ID: <i37kvt$18p$2@dough.gmane.org>

On 03/08/2010 00:24, Antoine Pitrou wrote:
> On Tue, 03 Aug 2010 00:00:46 +0100
> Mark Lawrence<breamoreboy at yahoo.co.uk>  wrote:
>>
>> Fly back at me if you like.  I don't care about me.  I don't care about
>> you.  I do care about Python.
>
> Well, you should care about people. Free software is as much as about
> building welcoming communities than it is about writing good software.
>
> Regards
>
> Antoine.
>
>
Do you build welcoming communities by ignoring posts for ten years?

Mark.


From benjamin at python.org  Tue Aug  3 01:57:56 2010
From: benjamin at python.org (Benjamin Peterson)
Date: Mon, 2 Aug 2010 18:57:56 -0500
Subject: [Python-Dev] No response to posts
In-Reply-To: <i37imv$rli$1@dough.gmane.org>
References: <i32g9g$ouf$1@dough.gmane.org> <4C54C5A4.6080409@netwok.org>
	<AANLkTinpB7yVhMSQ=Q9hMCA+SnF4p+zNH98-GZd4ZP+w@mail.gmail.com>
	<87r5ihm0k0.fsf@muni.brainbot.com>
	<AANLkTikDM0nCVT1S9Jg-ZySTnysBvK0qk0Jpta8WZG82@mail.gmail.com>
	<i372n8$2mg$1@dough.gmane.org>
	<AANLkTinhe5xfO+sswME-HuKK_ecfrdrhaGhzKPXZFL-7@mail.gmail.com>
	<i37imv$rli$1@dough.gmane.org>
Message-ID: <AANLkTikgjykw5BoXCupE7yy5qk8n8obdS60n8P+gMLA-@mail.gmail.com>

2010/8/2 Mark Lawrence <breamoreboy at yahoo.co.uk>:
> On 02/08/2010 22:18, Benjamin Peterson wrote:
>> I'm only referring to the infrastructure when I say "the current
>> setup." I don't think repeatedly tweaking the tracker is likely to
>> close more issues.
>>
>
> I find this response quite pathetic. ?The bulk of Terry's post has been
> snipped. ?My own earlier response has been ignored. ?Please Benjamin get out
> of your ivory tower, there are people such as myself who want to help, but
> we feel locked out.

You feel locked out by the current tracker?



-- 
Regards,
Benjamin

From steve at pearwood.info  Tue Aug  3 02:16:29 2010
From: steve at pearwood.info (Steven D'Aprano)
Date: Tue, 3 Aug 2010 10:16:29 +1000
Subject: [Python-Dev] No response to posts
In-Reply-To: <i372n8$2mg$1@dough.gmane.org>
References: <i32g9g$ouf$1@dough.gmane.org>
	<AANLkTikDM0nCVT1S9Jg-ZySTnysBvK0qk0Jpta8WZG82@mail.gmail.com>
	<i372n8$2mg$1@dough.gmane.org>
Message-ID: <201008031016.30020.steve@pearwood.info>

On Tue, 3 Aug 2010 04:27:53 am Terry Reedy wrote:
> On 8/2/2010 12:54 PM, Brian Curtin wrote:
> > On Mon, Aug 2, 2010 at 11:39, Ralf Schmitt <ralf at brainbot.com
> > <mailto:ralf at brainbot.com>> wrote:
> >
> >     Benjamin Peterson <benjamin at python.org
> > <mailto:benjamin at python.org>>
> >
> >     writes:
> >      > Please, let's stop messing with the tracker for everything.
> >      > I think the current set up works reasonably well, and we
> >      > should focus on the real problem: manpower
>
> Two months ago, I discovered and reported that about 1/5 of open
> issues had no responses. Is that 'reasonably well'? 

I don't know. What percentage of new issues get ever get a response? My 
wild guess is that it's probably about 99.9%, but the 0.1% that don't 
remain languishing forever, skewing the statistics. What's the average 
age of those 1 in 5 issues? Maybe 1 in 5 is exactly right, given the 
realities of people available to respond to issues versus people 
available to report issues. Maybe 1 in 5 is supernaturally good, given 
our resources available.



-- 
Steven D'Aprano

From barry at python.org  Tue Aug  3 02:25:25 2010
From: barry at python.org (Barry Warsaw)
Date: Mon, 2 Aug 2010 20:25:25 -0400
Subject: [Python-Dev] No response to posts
In-Reply-To: <AANLkTikgjykw5BoXCupE7yy5qk8n8obdS60n8P+gMLA-@mail.gmail.com>
References: <i32g9g$ouf$1@dough.gmane.org> <4C54C5A4.6080409@netwok.org>
	<AANLkTinpB7yVhMSQ=Q9hMCA+SnF4p+zNH98-GZd4ZP+w@mail.gmail.com>
	<87r5ihm0k0.fsf@muni.brainbot.com>
	<AANLkTikDM0nCVT1S9Jg-ZySTnysBvK0qk0Jpta8WZG82@mail.gmail.com>
	<i372n8$2mg$1@dough.gmane.org>
	<AANLkTinhe5xfO+sswME-HuKK_ecfrdrhaGhzKPXZFL-7@mail.gmail.com>
	<i37imv$rli$1@dough.gmane.org>
	<AANLkTikgjykw5BoXCupE7yy5qk8n8obdS60n8P+gMLA-@mail.gmail.com>
Message-ID: <20100802202525.14ebc162@heresy>

On Aug 02, 2010, at 06:57 PM, Benjamin Peterson wrote:

>You feel locked out by the current tracker?

I do, but that's only because bugs.python.org is currently pinin' for the
fjords. ;)

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100802/b45fbcf9/attachment.pgp>

From brett at python.org  Tue Aug  3 02:28:28 2010
From: brett at python.org (Brett Cannon)
Date: Mon, 2 Aug 2010 17:28:28 -0700
Subject: [Python-Dev] PEP 382 progress: import hooks
In-Reply-To: <20100723165435.BB08D3A409B@sparrow.telecommunity.com>
References: <4C483EDF.7050002@v.loewis.de>
	<20100722181939.1FA273A40D9@sparrow.telecommunity.com> 
	<AANLkTikDmiMG4j2m-vbEt=NyTzCLmeWSvNJY9Vj-9-kq@mail.gmail.com> 
	<20100723165435.BB08D3A409B@sparrow.telecommunity.com>
Message-ID: <AANLkTikCUgovEn57OXfGGA8p9sYAZ4DzrjXqHfEJOJU=@mail.gmail.com>

On Fri, Jul 23, 2010 at 09:54, P.J. Eby <pje at telecommunity.com> wrote:

> At 11:57 AM 7/23/2010 +0100, Brett Cannon wrote:
>
>
>
>  On Thu, Jul 22, 2010 at 19:19, P.J. Eby <<mailto:pje at telecommunity.com>
>> pje at telecommunity.com> wrote:
>>
>> What does "is not a package" actually mean in that context?
>>
>>
>> The module is a module but not a package.
>>
>
> Um...  that's not any clearer.  Are you saying that a module of the same
> name takes precedence over a package?  Is that the current precedence as
> well?
>

No, packages take precedence. I meant that something is a module but it is
not a package; a package implicitly includes a module, but a module is not
automatically a package.


>
>
>  Regarding load_module_with_path(), how does its specification differ from
>> simply creating a module in sys.modules, setting its __path__, and then
>> invoking the standard load_module()? ? (i.e., is this method actually
>> needed, since a correct PEP 302 loader *must* reuse an existing module
>> object in sys.modules)
>>
>>
>> It must reuse the module itself but a proper reload would reset __path__
>> as leaving it unchanged is not a proper resetting of the module object. So
>> this module is needed in order to force the loader
>>
>
> Um, no.  Reloading doesn't reset the module contents, not even __path__.
>  Never has, from Python 2.2 through 2.7 -- even in 3.1.  At least, not for
> normal filesystem .py/.pyc files.  (I tested with 'os', adding an extra
> 'foo' attribute, and also setting a __path__; both were unaffected by
> reload(), in all 7 Python versions.
>
> Perhaps you're saying this happens with zipfiles, or packages that already
> have a __path__, or...?
>

It's how I implemented it in importlib and it passes Python's unit test
suite that way; zipimport also does it this way as it too does not
differentiate a reload from a clean load beyond grabbing the module from
sys.modules if it is already there. PEP 302 does not directly state that
reloading should not reset the attributes that import must set, simply that
a module from sys.modules must be reused. Since zipimport does it this way I
wouldn't count on other loaders not setting __path__.


>
>
>
>>
>> Am I correct in understanding that, as written, one would have to redefine
>> __import__ to implement this in a library for older Python versions? ? Or is
>> it implementable as a meta_path importer?
>>
>>
>>
>> Redefine __import__ (unless Martin and I are missing something, but I
>> tried to think of how to implement this use sys.meta_path and couldn't come
>> up with a solution).
>>
>
> I'm thinking it *could* be done with a meta_path hook, but only by doubling
> the search length in the event that the search failed.  That seems a bit
> icky, but replacing the entire import process seems ickier (more code
> surface to maintain, more bug potential) in the case of supporting older
> Pythons.
>
>
I'm personally not worried about supporting older versions of Python as this
is a new feature. Better to design it properly than come up with some hack
solution as we will all have to live with this for a long time.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100802/38d9383f/attachment.html>

From nad at acm.org  Tue Aug  3 02:35:55 2010
From: nad at acm.org (Ned Deily)
Date: Mon, 02 Aug 2010 17:35:55 -0700
Subject: [Python-Dev] proto-pep: plugin proposal (for unittest)
References: <8a1ff5c3-3538-cbde-eece-ecc098fd2927@me.com>
	<20100802142458.44DEC219300@kimball.webabinitio.net>
	<4C56D814.4030804@voidspace.org.uk>
Message-ID: <nad-1C1B7C.17355502082010@news.gmane.org>

In article <4C56D814.4030804 at voidspace.org.uk>,
 Michael Foord <fuzzyman at voidspace.org.uk> wrote:
> Ronald was wrong when he said that the only configuration file in ~ used 
> by the Mac itself is .CFUserTextEncoding. Terminal (the Mac OS X command 
> line) has a user editable config file which it stores in ~.

Terminal.app does?  What file is that?

-- 
 Ned Deily,
 nad at acm.org


From steve at holdenweb.com  Tue Aug  3 03:28:53 2010
From: steve at holdenweb.com (Steve Holden)
Date: Mon, 02 Aug 2010 21:28:53 -0400
Subject: [Python-Dev] No response to posts
In-Reply-To: <i37kvt$18p$2@dough.gmane.org>
References: <i32g9g$ouf$1@dough.gmane.org>	<4C54C5A4.6080409@netwok.org>	<AANLkTinpB7yVhMSQ=Q9hMCA+SnF4p+zNH98-GZd4ZP+w@mail.gmail.com>	<87r5ihm0k0.fsf@muni.brainbot.com>	<AANLkTikDM0nCVT1S9Jg-ZySTnysBvK0qk0Jpta8WZG82@mail.gmail.com>	<i372n8$2mg$1@dough.gmane.org>	<AANLkTinhe5xfO+sswME-HuKK_ecfrdrhaGhzKPXZFL-7@mail.gmail.com>	<i37imv$rli$1@dough.gmane.org>	<20100803012424.48807800@pitrou.net>
	<i37kvt$18p$2@dough.gmane.org>
Message-ID: <4C5770D5.3050303@holdenweb.com>

On 8/2/2010 7:39 PM, Mark Lawrence wrote:
> On 03/08/2010 00:24, Antoine Pitrou wrote:
>> On Tue, 03 Aug 2010 00:00:46 +0100
>> Mark Lawrence<breamoreboy at yahoo.co.uk>  wrote:
>>>
>>> Fly back at me if you like.  I don't care about me.  I don't care about
>>> you.  I do care about Python.
>>
>> Well, you should care about people. Free software is as much as about
>> building welcoming communities than it is about writing good software.
>>
>> Regards
>>
>> Antoine.
>>
>>
> Do you build welcoming communities by ignoring posts for ten years?
> 
No, you don't, and the current discussion about how to ensure that bug
reporters get at least the courtesy of a relatively quick reply is one
of the most promising developments in building a welcoming community
that I can remember.

I realise that some people are happier focusing purely on technical
issues, and that's fine. But let's not let that stop us trying to build
a crew of ambassadors to take care of the more touchy-feely side of
things as long as it operates to the language's ultimate benefit.

It takes all sorts to make a world ...

regards
 Steve
-- 
Steve Holden           +1 571 484 6266   +1 800 494 3119
DjangoCon US September 7-9, 2010    http://djangocon.us/
See Python Video!       http://python.mirocommunity.org/
Holden Web LLC                 http://www.holdenweb.com/

From steve at holdenweb.com  Tue Aug  3 03:28:53 2010
From: steve at holdenweb.com (Steve Holden)
Date: Mon, 02 Aug 2010 21:28:53 -0400
Subject: [Python-Dev] No response to posts
In-Reply-To: <i37kvt$18p$2@dough.gmane.org>
References: <i32g9g$ouf$1@dough.gmane.org>	<4C54C5A4.6080409@netwok.org>	<AANLkTinpB7yVhMSQ=Q9hMCA+SnF4p+zNH98-GZd4ZP+w@mail.gmail.com>	<87r5ihm0k0.fsf@muni.brainbot.com>	<AANLkTikDM0nCVT1S9Jg-ZySTnysBvK0qk0Jpta8WZG82@mail.gmail.com>	<i372n8$2mg$1@dough.gmane.org>	<AANLkTinhe5xfO+sswME-HuKK_ecfrdrhaGhzKPXZFL-7@mail.gmail.com>	<i37imv$rli$1@dough.gmane.org>	<20100803012424.48807800@pitrou.net>
	<i37kvt$18p$2@dough.gmane.org>
Message-ID: <4C5770D5.3050303@holdenweb.com>

On 8/2/2010 7:39 PM, Mark Lawrence wrote:
> On 03/08/2010 00:24, Antoine Pitrou wrote:
>> On Tue, 03 Aug 2010 00:00:46 +0100
>> Mark Lawrence<breamoreboy at yahoo.co.uk>  wrote:
>>>
>>> Fly back at me if you like.  I don't care about me.  I don't care about
>>> you.  I do care about Python.
>>
>> Well, you should care about people. Free software is as much as about
>> building welcoming communities than it is about writing good software.
>>
>> Regards
>>
>> Antoine.
>>
>>
> Do you build welcoming communities by ignoring posts for ten years?
> 
No, you don't, and the current discussion about how to ensure that bug
reporters get at least the courtesy of a relatively quick reply is one
of the most promising developments in building a welcoming community
that I can remember.

I realise that some people are happier focusing purely on technical
issues, and that's fine. But let's not let that stop us trying to build
a crew of ambassadors to take care of the more touchy-feely side of
things as long as it operates to the language's ultimate benefit.

It takes all sorts to make a world ...

regards
 Steve
-- 
Steve Holden           +1 571 484 6266   +1 800 494 3119
DjangoCon US September 7-9, 2010    http://djangocon.us/
See Python Video!       http://python.mirocommunity.org/
Holden Web LLC                 http://www.holdenweb.com/


From dstanek at dstanek.com  Tue Aug  3 03:29:36 2010
From: dstanek at dstanek.com (David Stanek)
Date: Mon, 2 Aug 2010 21:29:36 -0400
Subject: [Python-Dev] Tracker status
In-Reply-To: <AANLkTi=fcQJP6SuNSz35+HpCzeDVY8bYEs2VtLS2Mq2z@mail.gmail.com>
References: <AANLkTi=fcQJP6SuNSz35+HpCzeDVY8bYEs2VtLS2Mq2z@mail.gmail.com>
Message-ID: <AANLkTi=a5KhS-X_Ec=2pUbzH71MSNgfrkeYT=qUEehto@mail.gmail.com>

On Mon, Aug 2, 2010 at 6:17 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> Are the bug tracker and meta-tracker down for anyone else, or is it just me?
>

It is down for me as well. It appears to be accepting the connection
and then just doesn't return any content.

-- 
David
blog: http://www.traceback.org
twitter: http://twitter.com/dstanek

From rdmurray at bitdance.com  Tue Aug  3 03:51:11 2010
From: rdmurray at bitdance.com (R. David Murray)
Date: Mon, 02 Aug 2010 21:51:11 -0400
Subject: [Python-Dev] [Python-checkins] r83543 -
	python/branches/py3k/Lib/test/regrtest.py
In-Reply-To: <20100802185952.CF6BDEEA92@mail.python.org>
References: <20100802185952.CF6BDEEA92@mail.python.org>
Message-ID: <20100803015111.DC2E01F451D@kimball.webabinitio.net>

On Mon, 02 Aug 2010 20:59:52 +0200, georg.brandl <python-checkins at python.org> wrote:
> Author: georg.brandl
> Date: Mon Aug  2 20:59:52 2010
> New Revision: 83543
> 
> Log:
> #8560: add progress indicator to regrtest.
[...]
> @@ -517,6 +517,9 @@
>      else:
>          tests = iter(selected)
>  
> +    tests = list(tests)

I guess you didn't notice that just above this code is a clause that
says 'if forever' which implements -F/--forever by making tests into a
generator that never runs out...

--
R. David Murray                                      www.bitdance.com

From ysj.ray at gmail.com  Tue Aug  3 03:54:39 2010
From: ysj.ray at gmail.com (Ray Allen)
Date: Tue, 3 Aug 2010 09:54:39 +0800
Subject: [Python-Dev] Tracker status
In-Reply-To: <AANLkTi=a5KhS-X_Ec=2pUbzH71MSNgfrkeYT=qUEehto@mail.gmail.com>
References: <AANLkTi=fcQJP6SuNSz35+HpCzeDVY8bYEs2VtLS2Mq2z@mail.gmail.com>
	<AANLkTi=a5KhS-X_Ec=2pUbzH71MSNgfrkeYT=qUEehto@mail.gmail.com>
Message-ID: <AANLkTimO9mYR_u3ghrZNGmPP6puqiP-g7OW9g92c4rjV@mail.gmail.com>

Down for me as well. Initially I though it was shield by "Great Firewall" since
I'm from China.

On Tue, Aug 3, 2010 at 9:29 AM, David Stanek <dstanek at dstanek.com> wrote:

> On Mon, Aug 2, 2010 at 6:17 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> > Are the bug tracker and meta-tracker down for anyone else, or is it just
> me?
> >
>
> It is down for me as well. It appears to be accepting the connection
> and then just doesn't return any content.
>
> --
> David
> blog: http://www.traceback.org
> twitter: http://twitter.com/dstanek
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/ysj.ray%2Bpython-dev%40gmail.com
>



-- 
Ray Allen
Best wishes!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100803/f8ef94ec/attachment-0001.html>

From barry at python.org  Tue Aug  3 04:07:34 2010
From: barry at python.org (Barry Warsaw)
Date: Mon, 2 Aug 2010 22:07:34 -0400
Subject: [Python-Dev] Postponing 2.6.6rc1
Message-ID: <20100802220734.10669caf@heresy>

For several reasons, I'm postponing 2.6.6rc1 for one day.  Ezio has been doing
a lot of great work on the test suite, but there are still a few things to
fix.  On top of that, bugs.python.org crashed and we're waiting for our
hosting company to wake up and reboot it.

We'll try again, same time tomorrow: 2200 UTC.  Come join us on #python-dev if
you want to watch the circus. :)

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100802/d19e1c1e/attachment.pgp>

From rdmurray at bitdance.com  Tue Aug  3 05:00:39 2010
From: rdmurray at bitdance.com (R. David Murray)
Date: Mon, 02 Aug 2010 23:00:39 -0400
Subject: [Python-Dev] checkins reply-to change
In-Reply-To: <20100803015111.DC2E01F451D@kimball.webabinitio.net>
References: <20100802185952.CF6BDEEA92@mail.python.org>
	<20100803015111.DC2E01F451D@kimball.webabinitio.net>
Message-ID: <20100803030039.7D85B2004F1@kimball.webabinitio.net>

On Mon, 02 Aug 2010 21:51:11 -0400, "R. David Murray" <rdmurray at bitdance.com> wrote:
> On Mon, 02 Aug 2010 20:59:52 +0200, georg.brandl <python-checkins at python.org> wrote:
> > Author: georg.brandl
> > Date: Mon Aug  2 20:59:52 2010
> > New Revision: 83543

Hmm.  Looking at the format of this message as it came back to me,
I can see that the change to the Reply-To for checkins breaks my email
filtering.  Previously I could catch replies to my checkins by looking
for my committer id in the 'To' field, and I would put those in a special
folder, and so I would see right away that I had a message.  Now they
just wind up in the general python-dev and python-checkins folders,
which I do not necessarily read every day.  So this change will actually
slow down my noticing replies.

I can't see any reliable identifying characteristic of the message
which I could use to move it into the 'alert' folder.  Checking the
message body for 'r.david.murray <python-checkins at python-org>' will work most of
the time, if people's email clients follow the normal quoting conventions
and the reply header is left in.  But it isn't going to be 100% reliable.

Would it be possible to include the committer id in the 'realname'
field on the To address? (Or on the CC address).

--
R. David Murray                                      www.bitdance.com

From ezio.melotti at gmail.com  Tue Aug  3 05:04:56 2010
From: ezio.melotti at gmail.com (Ezio Melotti)
Date: Tue, 03 Aug 2010 06:04:56 +0300
Subject: [Python-Dev] [Python-checkins] r83596 - in
 python/branches/release26-maint: Doc/library/constants.rst
In-Reply-To: <20100802214704.85C8AEEC29@mail.python.org>
References: <20100802214704.85C8AEEC29@mail.python.org>
Message-ID: <4C578757.1060102@gmail.com>

  Hi,

On 03/08/2010 0.47, georg.brandl wrote:
> Author: georg.brandl
> Date: Mon Aug  2 23:47:02 2010
> New Revision: 83596
>
> Log:
> Merged revisions 83567 via svnmerge from
> svn+ssh://pythondev at svn.python.org/python/branches/release27-maint
>
> ................
>    r83567 | georg.brandl | 2010-08-02 22:32:03 +0200 (Mo, 02 Aug 2010) | 9 lines
>
>    Merged revisions 83552 via svnmerge from
>    svn+ssh://pythondev at svn.python.org/python/branches/py3k
>
>    ........
>      r83552 | georg.brandl | 2010-08-02 21:36:36 +0200 (Mo, 02 Aug 2010) | 1 line
>
>      #9438: clarify that constant names also cannot be assigned as attributes.
>    ........
> ................
>
>
> Modified:
>     python/branches/release26-maint/   (props changed)
>     python/branches/release26-maint/Doc/library/constants.rst
>
> Modified: python/branches/release26-maint/Doc/library/constants.rst
> ==============================================================================
> --- python/branches/release26-maint/Doc/library/constants.rst	(original)
> +++ python/branches/release26-maint/Doc/library/constants.rst	Mon Aug  2 23:47:02 2010
> @@ -3,7 +3,6 @@
>
>   A small number of constants live in the built-in namespace.  They are:
>
> -
>   .. data:: False
>
>      The false value of the :class:`bool` type.
> @@ -39,16 +38,23 @@
>
>      Special value used in conjunction with extended slicing syntax.
>
> -   .. XXX Someone who understands extended slicing should fill in here.
> -
>
>   .. data:: __debug__
>
>      This constant is true if Python was not started with an :option:`-O` option.
> -   Assignments to :const:`__debug__` are illegal and raise a :exc:`SyntaxError`.
>      See also the :keyword:`assert` statement.
>
>
> +.. note::
> +
> +   The names :data:`None` and :data:`__debug__` cannot be reassigned
> +   (assignments to them, even as an attribute name, raise :exc:`SyntaxError`),
> +   so they can be considered "true" constants.
> +
> +   .. versionchanged:: 2.7
> +      Assignments to ``__debug__`` as an attribute became illegal.

this shouldn't be here.

> +
> +
>   Constants added by the :mod:`site` module
>   -----------------------------------------
>
> _______________________________________________
> Python-checkins mailing list
> Python-checkins at python.org
> http://mail.python.org/mailman/listinfo/python-checkins
>

Best Regards,
Ezio Melotti

From eliben at gmail.com  Tue Aug  3 05:40:52 2010
From: eliben at gmail.com (Eli Bendersky)
Date: Tue, 3 Aug 2010 06:40:52 +0300
Subject: [Python-Dev] co_firstlineno on decorated functions
In-Reply-To: <AANLkTinTg6TuJesKKKVCj-5RcLbit75JTtjrF794qUs-@mail.gmail.com>
References: <AANLkTinTg6TuJesKKKVCj-5RcLbit75JTtjrF794qUs-@mail.gmail.com>
Message-ID: <AANLkTi=7_nNcQ0bcWmtiy8E0-P8Z6doHT-A_wPSdiOum@mail.gmail.com>

[Since I received no replies on this in python-list, perhaps python-dev is
more appropriate]


Hello,

I've been tinkering with __code__.co_firstlineno for testing the trace.py
module (Python Issue 9315), and ran into an interesting problem. Consider
this code:


def dummydecorator(f):
    return f

def foo(a):
    return a

@dummydecorator
def bar(a):
    return a


if __name__ == "__main__":
    print foo.__code__.co_firstlineno
    print bar.__code__.co_firstlineno

----
The first print out correctly specifies the line "def foo" is in. However,
the second one points to the line with "@dummydecorator" instead of "def
bar". [Python 2.6]

The side-effects of this behavior can be easily seen in the output of
modules like trace and profile. Would you say it's normal, or could this be
considered a bug?

Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100803/069d2b81/attachment.html>

From pje at telecommunity.com  Tue Aug  3 05:58:53 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Mon, 02 Aug 2010 23:58:53 -0400
Subject: [Python-Dev] PEP 382 progress: import hooks
In-Reply-To: <AANLkTikCUgovEn57OXfGGA8p9sYAZ4DzrjXqHfEJOJU=@mail.gmail.c
 om>
References: <4C483EDF.7050002@v.loewis.de>
	<20100722181939.1FA273A40D9@sparrow.telecommunity.com>
	<AANLkTikDmiMG4j2m-vbEt=NyTzCLmeWSvNJY9Vj-9-kq@mail.gmail.com>
	<20100723165435.BB08D3A409B@sparrow.telecommunity.com>
	<AANLkTikCUgovEn57OXfGGA8p9sYAZ4DzrjXqHfEJOJU=@mail.gmail.com>
Message-ID: <20100803035852.406323A47A6@sparrow.telecommunity.com>

At 05:28 PM 8/2/2010 -0700, Brett Cannon wrote:


>On Fri, Jul 23, 2010 at 09:54, P.J. Eby 
><<mailto:pje at telecommunity.com>pje at telecommunity.com> wrote:
>At 11:57 AM 7/23/2010 +0100, Brett Cannon wrote:
>
>
>
>On Thu, Jul 22, 2010 at 19:19, P.J. Eby 
><<mailto:pje at telecommunity.com>pje at telecommunity.com> wrote:
>
>What does "is not a package" actually mean in that context?
>
>
>The module is a module but not a package.
>
>
>Um... ? that's not any clearer. ? Are you saying that a module of 
>the same name takes precedence over a package? ? Is that the current 
>precedence as well?
>
>
>No, packages take precedence. I meant that something is a module but 
>it is not a package; a package implicitly includes a module, but a 
>module is not automatically a package.

That explanation still isn't making things any clearer for me.  That 
is, I don't know how to get from that statement to actual code, even 
if I were writing a filesystem or zip importer, let alone anything more exotic.


>  zipimport also does it this way as it too does not differentiate a 
> reload from a clean load beyond grabbing the module from 
> sys.modules if it is already there. PEP 302 does not directly state 
> that reloading should not reset the attributes that import must 
> set, simply that a module from sys.modules must be reused. Since 
> zipimport does it this way I wouldn't count on other loaders not 
> setting __path__.

Fair enough, though certainly unfortunate.  In particular, it means 
that it's not actually possible to correctly/completely implement PEP 
382 on any already-released version of Python, without essentially 
replacing zipimport.  (Unless the spec can be tweaked a bit.)


>I'm personally not worried about supporting older versions of Python 
>as this is a new feature. Better to design it properly than come up 
>with some hack solution as we will all have to live with this for a long time.

Currently, older Pythons are the only versions I *do* support, so I'm 
very concerned with it.  Otherwise, I'd not be asking all these questions.  ;-)

Personally, I think there are features in the PEP that make things 
unnecessarily complicated - for example, supporting both __init__.py 
*and* .pth files in the same directory.  If it were either/or, it 
would be a LOT easier to implement on older Pythons, since it 
wouldn't matter when you initialized the __path__ in that case.

(By the way, there were some other questions I asked about the PEP 
382 revisions, that you didn't reply to in previous emails (such as 
the format of the strings to be returned by find_path()); I hope 
either you or Martin can fill those in for me, and hopefully update 
the PEP with the things we have talked about in this thread.)


From stephen at xemacs.org  Tue Aug  3 06:02:01 2010
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Tue, 03 Aug 2010 13:02:01 +0900
Subject: [Python-Dev] No response to posts
In-Reply-To: <i36kg3$1ql$1@dough.gmane.org>
References: <i32g9g$ouf$1@dough.gmane.org>
	<AANLkTi=5xfXtYbRbe8ZD5XmG7vApWZhbnm-vk3qq13Xg@mail.gmail.com>
	<i338g6$9o7$1@dough.gmane.org>
	<AANLkTin7oUUcOZFqBQnRe+0PFSPj78bEtD9p179YMe4Z@mail.gmail.com>
	<4C555E24.9040007@netwok.org> <i34v48$8lc$1@dough.gmane.org>
	<i350gg$blm$1@dough.gmane.org>
	<878w4ptmrd.fsf@uwakimon.sk.tsukuba.ac.jp>
	<i36kg3$1ql$1@dough.gmane.org>
Message-ID: <87y6cos5s6.fsf@uwakimon.sk.tsukuba.ac.jp>

Ron Adam writes:

 > Yes, but when I do it, I either get a single specific day, or 2700
 > issues.

If your query specifies an activity date, you will get only issues
with activity that date.  If it sorts or groups on activity date, you
will get all issues (subject to other conditions), but you can easily
view either the first 50 or the last 50 by choosing direction of sort.

 > Have you tried it?  I tried various different spelling and could
 > only enter one specific day, "today" works, but "1 month" or "2
 > years" doesn't.

I hadn't tried it at that time; I just stated a general fact about
Roundup's capabilities.  Sorry for not making that clear.

A correct interval syntax, which was tested and works in the creation
and activity fields of XEmacs's Roundup tracker (Python's is refusing
to talk to me at the moment) is "from 2010-06-01 to 2010-07-31".
Another is "from -1m" (meaning from one month ago to now; other units
are "y" for year and "d" for day).

Many others are described in the Roundup User guide.  I don't have an
URL for the current upstream version offhand, but one adapted for
XEmacs's tracker is here:

http://tracker.xemacs.org/XEmacs/its/@@file/user_guide.html#interval-properties

(this part is just the upstream version verbatim, a couple years old).

 > What does work is entering a partial date, ie...  2010-07 for all issues 
 > with activity this july. Or 2010 for all issues with activity this year.

Warning: This didn't work as expected for me with the "from ... to
..."  syntax.  Apparently in from/to syntax, a number with no hyphens
is interpreted as day-of-month, and with one hyphen it's month-day,
with no sanity checking.  I'm not sure what it thinks 2010-07 means,
but it gave me everything in our tracker. :-)

From stephen at xemacs.org  Tue Aug  3 06:28:51 2010
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Tue, 03 Aug 2010 13:28:51 +0900
Subject: [Python-Dev] No response to posts
In-Reply-To: <i37iu1$rli$2@dough.gmane.org>
References: <i32g9g$ouf$1@dough.gmane.org> <4C54C5A4.6080409@netwok.org>
	<AANLkTinpB7yVhMSQ=Q9hMCA+SnF4p+zNH98-GZd4ZP+w@mail.gmail.com>
	<87r5ihm0k0.fsf@muni.brainbot.com>
	<AANLkTikDM0nCVT1S9Jg-ZySTnysBvK0qk0Jpta8WZG82@mail.gmail.com>
	<i372n8$2mg$1@dough.gmane.org>
	<AANLkTinhe5xfO+sswME-HuKK_ecfrdrhaGhzKPXZFL-7@mail.gmail.com>
	<AANLkTik+sFUL11yeMFFrx5wB0yYWLF3nUNtwe3kGo_Mj@mail.gmail.com>
	<AANLkTimr4EavemsRaWaYz53iyOpSutdb6hqcdfaNiv8A@mail.gmail.com>
	<20100803004353.14607c91@pitrou.net> <i37iu1$rli$2@dough.gmane.org>
Message-ID: <87wrs8s4jg.fsf@uwakimon.sk.tsukuba.ac.jp>

Mark Lawrence writes:

 > I completely disagree.

Mark, please stop being disagreeable.<wink>  The above is *not true*.
You've made no statements I can recall insisting that the only way to
skin a cat is to use a GNOME theme, only that the cat needs skinning.

Before you posted that, Benjamin had already clarified that his worry
is that new fields will be added to the tracker, or available values
for some fields will be changed.  He's right, experience shows that
adding fields to the tracker confuses reporters and responders alike,
unless it's done very carefully.

But he has no objection to improving the tracker's reporting
capabilities.  I think the tracker currently has plenty of information
to do a much better job of responding in a timely fashion than was
done in the past, so there's plenty of room for you to do your work
without imposing new bureaucracy on others, yes?  There's no real
disagreement here (unless you think it would be a good idea for
Benjamin to stop doing release manager and do issue triage instead, in
which case, I certainly hope he disagrees!<wink>)



From stephen at xemacs.org  Tue Aug  3 07:06:09 2010
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Tue, 03 Aug 2010 14:06:09 +0900
Subject: [Python-Dev] No response to posts
In-Reply-To: <201008031016.30020.steve@pearwood.info>
References: <i32g9g$ouf$1@dough.gmane.org>
	<AANLkTikDM0nCVT1S9Jg-ZySTnysBvK0qk0Jpta8WZG82@mail.gmail.com>
	<i372n8$2mg$1@dough.gmane.org>
	<201008031016.30020.steve@pearwood.info>
Message-ID: <87vd7ss2ta.fsf@uwakimon.sk.tsukuba.ac.jp>

Steven D'Aprano writes:

 > I don't know. What percentage of new issues get ever get a response? My 
 > wild guess is that it's probably about 99.9%, but the 0.1% that don't 
 > remain languishing forever, skewing the statistics.

No guess needed, we have the data.  If the fraction "a" of issues ever
opened is still open, and 1 in 5 open issues has no responses, then
the fraction of issues that ever got a response is 4a/5 + (1 - a).
(This assumes that closing an issue counts as a response, which I
think is entirely reasonable.)

The actual value of a is currently 13.2%, which means that about 1/9 *
1/5 = one in 45 of new issues has never received any response.  IMO,
that's pretty good.  I don't think it's worth doing anything about,
beyond giving Mark and those who volunteer with him better tools for
their work.  But that much should be done (again IMO).

To add an anecdote to those already presented, back when I was
completely new to Internet-based software development, I had an Emacs
bug that was making my life miserable.  I really wanted to do the
Right Thing and support the GNU project, but it was the XEmacs
developers that responded with interest (but zero help beyond some
random suggestions that didn't pan out -- the guy who knew something
about it had a different X implementation and it worked for him).  You
can see the difference that response made to *my* life in my email
address.

From mal at egenix.com  Tue Aug  3 10:00:44 2010
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue, 03 Aug 2010 10:00:44 +0200
Subject: [Python-Dev] PEP 376 proposed changes for basic plugins support
In-Reply-To: <4C574F96.9050200@netwok.org>
References: <AANLkTinyjMkF2n91zS+48n6B_gkp9szW_bH0XJgTDh7D@mail.gmail.com>	<4C55FF0F.3010702@voidspace.org.uk>	<AANLkTim1af-zWEYF4U-vTr6d+8HkqFCycMVmQYsqpDcN@mail.gmail.com>	<4C5609A3.3090008@voidspace.org.uk>	<AANLkTimU-OUh8fzFoRvHMsQOqVa+jsFTfPyZKeY=heVg@mail.gmail.com>	<20100802010616.5FD133A4758@sparrow.telecommunity.com>	<AANLkTi=UDktBHXeQTU6_ouPk2sfnmhztMLY9yjzZJHP7@mail.gmail.com>	<4C56B846.9090009@egenix.com>	<20100802123145.2305.1286368223.divmod.xquotient.3@localhost.localdomain>	<4C56C57C.4000800@voidspace.org.uk>	<4C571E42.9040408@egenix.com>
	<4C574F96.9050200@netwok.org>
Message-ID: <4C57CCAC.1050406@egenix.com>

?ric Araujo wrote:
>> What you might want to do is add new type fields to PEP 345,
>> making it easier to identify and list packages that work as
>> plugins for applications, e.g.
>>
>> Type: Plugin for MyCoolApp
>>
>> The MyCoolApp could then use the Type-field to identify all
>> installed plugins, get their installation directories, etc.
>> and work on from there.
> 
> Classifiers seem a good way to do that. They?re already defined in
> accepted PEPs, extensible on demand, used by Web frameworks
> components/applications/middlewares/things and other projects, and
> queriable in PyPI.
> 
> We could use ?Environment :: Plugins? and ?Framework :: Something? or
> define a new classifier (not all applications are frameworks, and
> ?plugins? seems a very strange value for ?environment?).

This would work to mark plugins as such, but we'd still would
have to have a field to name the app they belong to and
I don't think that the process of adding new classifiers is
flexible enough to handle those names.

A Type field would be under application control and allow easy
discovery of installed plugins for a specific app.

> It would be the first time that a classifier triggers specific
> processing from distutils though, so we may prefer to define a new
> Provides-Plugin field for consistency and explicitness.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Aug 03 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/
________________________________________________________________________

::: 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/

From mal at egenix.com  Tue Aug  3 10:28:07 2010
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue, 03 Aug 2010 10:28:07 +0200
Subject: [Python-Dev] PEP 376 proposed changes for basic plugins support
In-Reply-To: <20100802213104.E6EFC3A479B@sparrow.telecommunity.com>
References: <AANLkTinyjMkF2n91zS+48n6B_gkp9szW_bH0XJgTDh7D@mail.gmail.com>	<4C55FF0F.3010702@voidspace.org.uk>	<AANLkTim1af-zWEYF4U-vTr6d+8HkqFCycMVmQYsqpDcN@mail.gmail.com>	<4C5609A3.3090008@voidspace.org.uk>	<AANLkTimU-OUh8fzFoRvHMsQOqVa+jsFTfPyZKeY=heVg@mail.gmail.com>	<20100802010616.5FD133A4758@sparrow.telecommunity.com>	<AANLkTi=UDktBHXeQTU6_ouPk2sfnmhztMLY9yjzZJHP7@mail.gmail.com>	<4C56B846.9090009@egenix.com>	<20100802123145.2305.1286368223.divmod.xquotient.3@localhost.localdomain>	<4C56C57C.4000800@voidspace.org.uk>
	<4C571E42.9040408@egenix.com>	<4C57247F.5060105@voidspace.org.uk>
	<4C572C93.4040207@egenix.com>
	<20100802213104.E6EFC3A479B@sparrow.telecommunity.com>
Message-ID: <4C57D317.8080707@egenix.com>

P.J. Eby wrote:
> At 10:37 PM 8/2/2010 +0200, M.-A. Lemburg wrote:
>> If that's the case, then it would be better to come up with an
>> idea of how to make access to that meta-data available in a less
>> I/O intense way, e.g. by having pip or other package managers update
>> a central SQLite database cache of the data found on disk.
> 
> Don't forget system packaging tools like .deb, .rpm, etc., which do not
> generally take kindly to updating such things.  For better or worse, the
> filesystem *is* our "central database" these days.

I don't think that's a problem: the SQLite database would be a cache
like e.g. a font cache or TCSH command cache, not a replacement of
the meta files stored in directories.

Such a database would solve many things at once: faster access to
the meta-data of installed packages, fewer I/O calls during startup,
more flexible ways of doing queries on the meta-data, needed for
introspection and discovery, etc.

> Btw, while adding PLUGINS to PEP 376 is a new proposal, it's essentially
> another spelling of the existing entry_points.txt used by eggs; it
> changes the format to csv instead of .ini, and adds "description" and
> "type" fields, but drops requirements information and I'm not sure if it
> can point to arbitrary objects the way entry_points.txt can.
> 
> Anyway, entry_points.txt has been around enough years in the field that
> the concept itself can't really be called "new" - it's actually quite
> proven.  Checking
> http://nullege.com/codes/search/pkg_resources.iter_entry_points/call , I
> find 187 modules using just that one entry points API.
> 
> Some projects do have more than one module loading plugins, but the
> majority of those 187 appear to be different projects.
> 
> Note that that's modules *loading plugins*, not plugins being
> provided...  so the total number of PyPI projects using entry points in
> some way is likely much higher, once you add in the plugins that these
> 187 lookups are, well, looking up.

setuptools entry points are just one way of doing plugins. There
are other such systems that work well and which do not require
any special administration or setup, simply because the application
using the plugins defines the plugin protocol.

Since you are into comparing numbers, you might want to count
the number of Zope plugins that are available on PyPI and its plugin
system has been around much longer than setuptools has been.
I don't think that proves anything, though.

I simply don't see a good reason to complicate the Python
packaging system by trying to add a particular plugin support
to it.

Plugins are application scope features and should be treated
as such.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Aug 03 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/
________________________________________________________________________

::: 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/

From stephen at xemacs.org  Tue Aug  3 10:56:10 2010
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Tue, 03 Aug 2010 17:56:10 +0900
Subject: [Python-Dev] No response to posts
In-Reply-To: <4C5770D5.3050303@holdenweb.com>
References: <i32g9g$ouf$1@dough.gmane.org> <4C54C5A4.6080409@netwok.org>
	<AANLkTinpB7yVhMSQ=Q9hMCA+SnF4p+zNH98-GZd4ZP+w@mail.gmail.com>
	<87r5ihm0k0.fsf@muni.brainbot.com>
	<AANLkTikDM0nCVT1S9Jg-ZySTnysBvK0qk0Jpta8WZG82@mail.gmail.com>
	<i372n8$2mg$1@dough.gmane.org>
	<AANLkTinhe5xfO+sswME-HuKK_ecfrdrhaGhzKPXZFL-7@mail.gmail.com>
	<i37imv$rli$1@dough.gmane.org> <20100803012424.48807800@pitrou.net>
	<i37kvt$18p$2@dough.gmane.org> <4C5770D5.3050303@holdenweb.com>
Message-ID: <87r5igrs5x.fsf@uwakimon.sk.tsukuba.ac.jp>

Steve Holden writes:

 > No, you don't, and the current discussion about how to ensure that bug
 > reporters get at least the courtesy of a relatively quick reply is one
 > of the most promising developments in building a welcoming community
 > that I can remember.

C'mon Steve, it's not hard to see that's unfair.  Mark deserves to be
complimented for the work he's doing, that side of your comment is
perfectly fair, but you of all people should take care to recognize
that python-dev is "welcoming people to the community" every day.

As Steven d'Aprano pointed out (admittedly with a bit of hyperbole) a
very high percentage of issues (about 97%) do get some response, and
nearly 87% of all issues ever submitted to Python have already been
closed (based on the end-of-July tracker summary).  Remember that many
of those that are still open are open because nobody's willing to call
them "walking dead" and close them as "unsalvagable."  Any serious
effort at triage by the people who would do the work to resolve them
will surely result in a very large fraction closed with "wontfix",
what is known as "a self-fulfilling prophecy".  It's not clear that's
a win; some users surely think so, others not.

Now, let's take a look at some recent numbers about issue flows.  Of
the 264 issues submitted in June, 126 (47.7%) have already been
closed.  Of the 138 still open, 38 (27.5% of open issues) have
activity in July, meaning that 62.1% of the sample of 264 recent
issues have either been resolved or are receiving ongoing support (and
maybe better than that).[1][2]

In fact, the numbers I'm looking at are really promising, too, and the
whole Python crew deserves a big round of applause for producing them
every day!  Those numbers mean that not only have hundreds of users
been "welcomed to the community", but a huge majority of them got some
kind of fix for their problems, too, or at least a comment from a
qualified expert.  That compares very favorably with my experience
with other products, both commercial and volunteer-developed.

I don't claim that these numbers are a reason for doing nothing about
issues that have been hanging fire for years.  But it clearly suggests
that those hangfires are mostly very hard issues for some reason.
They are not a systematic problem with the project's overall response
to issues; it is extremely effective in dealing with them.

What's left is a pure PR effort:

 > But let's not let that stop us trying to build a crew of
 > ambassadors to take care of the more touchy-feely side of things as
 > long as it operates to the language's ultimate benefit.

Nobody's interfering with that *at all*.  In fact, it's quite clear
that everybody is happy with Mark's work, and wants him to continue.
They just want him to give up on the idea that they're going to put in
a lot more effort on resolving issues than they already do, and his
claim that something's horribly wrong.  The numbers above show why.


Footnotes: 
[1]  "June" and "July" are approximations.  First, *creation date* was
queried with "from -2m to -1m", and then was filtered with *activity*
"from -1m" and *status* "open".

[2]  These are conservative estimates of activity in my opinion.  Eg,
depending on how many of the open issues not touched in July are
waiting on OP response, return of a developer from vacation, or
perhaps a release before being committed to a branch, it may be that
the number of issues waiting for developer attention is much smaller
than 100.

It's hard to develop more precise statistics, and this is obviously
not a random sample.  But the sample is probably not unrepresentative.
The corresponding numbers for May submissions, closures to date, and
June-July activity are 281, 151 (53.7%), and 44 (33.8% of still open
issues).  Interestingly enough, for issues submitted in May and still
open, the June activity is 23 and the July activity is 21, so they are
entirely disjoint!  This means that delays of a month or so don't
imply that an issue is being dropped on the floor at all in the May
sample, just that half the time it takes a developer a month or two to
get to his issues.

Footnote 1 applies here, too.

From songofacandy at gmail.com  Tue Aug  3 11:19:11 2010
From: songofacandy at gmail.com (INADA Naoki)
Date: Tue, 3 Aug 2010 18:19:11 +0900
Subject: [Python-Dev] logging package vs unicode
In-Reply-To: <4C31D14D.5010001@simplistix.co.uk>
References: <4C31D14D.5010001@simplistix.co.uk>
Message-ID: <AANLkTinhMF4AWKbYxjmQ=BquBAsbO1T77L2zxPbGJsSZ@mail.gmail.com>

FWIW, I think the best way to avoid UnicodeError is: Don't use chars
out of ASCII in Python2.
I prefer '%r' to '%s' because it escapes chars not printable or out of
ASCII with backslash.

On Mon, Jul 5, 2010 at 9:34 PM, Chris Withers <chris at simplistix.co.uk> wrote:
> Hi All,
>
> The documentation for the logging package doesn't include any mention of
> unicode.
>
> What's the recommended usage in terms of passing unicode vs encoded strings?
>
> How does this differ from Python 2 to Python 3?
>
> cheers,
>
> Chris
>
> --
> Simplistix - Content Management, Batch Processing & Python Consulting
> ? ? ? ? ? ?- http://www.simplistix.co.uk
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/songofacandy%40gmail.com
>



-- 
INADA Naoki? <songofacandy at gmail.com>

From fuzzyman at voidspace.org.uk  Tue Aug  3 13:09:00 2010
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Tue, 03 Aug 2010 12:09:00 +0100
Subject: [Python-Dev] PEP 376 proposed changes for basic plugins support
In-Reply-To: <4C57D317.8080707@egenix.com>
References: <AANLkTinyjMkF2n91zS+48n6B_gkp9szW_bH0XJgTDh7D@mail.gmail.com>	<4C55FF0F.3010702@voidspace.org.uk>	<AANLkTim1af-zWEYF4U-vTr6d+8HkqFCycMVmQYsqpDcN@mail.gmail.com>	<4C5609A3.3090008@voidspace.org.uk>	<AANLkTimU-OUh8fzFoRvHMsQOqVa+jsFTfPyZKeY=heVg@mail.gmail.com>	<20100802010616.5FD133A4758@sparrow.telecommunity.com>	<AANLkTi=UDktBHXeQTU6_ouPk2sfnmhztMLY9yjzZJHP7@mail.gmail.com>	<4C56B846.9090009@egenix.com>	<20100802123145.2305.1286368223.divmod.xquotient.3@localhost.localdomain>	<4C56C57C.4000800@voidspace.org.uk>
	<4C571E42.9040408@egenix.com>	<4C57247F.5060105@voidspace.org.uk>
	<4C572C93.4040207@egenix.com>
	<20100802213104.E6EFC3A479B@sparrow.telecommunity.com>
	<4C57D317.8080707@egenix.com>
Message-ID: <4C57F8CC.8000708@voidspace.org.uk>

On 03/08/2010 09:28, M.-A. Lemburg wrote:
> P.J. Eby wrote:
>    
>> At 10:37 PM 8/2/2010 +0200, M.-A. Lemburg wrote:
>>      
>>> If that's the case, then it would be better to come up with an
>>> idea of how to make access to that meta-data available in a less
>>> I/O intense way, e.g. by having pip or other package managers update
>>> a central SQLite database cache of the data found on disk.
>>>        
>> Don't forget system packaging tools like .deb, .rpm, etc., which do not
>> generally take kindly to updating such things.  For better or worse, the
>> filesystem *is* our "central database" these days.
>>      
> I don't think that's a problem: the SQLite database would be a cache
> like e.g. a font cache or TCSH command cache, not a replacement of
> the meta files stored in directories.
>
> Such a database would solve many things at once: faster access to
> the meta-data of installed packages, fewer I/O calls during startup,
> more flexible ways of doing queries on the meta-data, needed for
> introspection and discovery, etc.
>    

Sounds good as an "optional extra" (i.e. it should be safe to completely 
delete the cache file and still have everything work) to me. If the API 
for using the feature is worked out well first this could be done as a 
behind the scenes optimisation...

>    
>> Btw, while adding PLUGINS to PEP 376 is a new proposal, it's essentially
>> another spelling of the existing entry_points.txt used by eggs; it
>> changes the format to csv instead of .ini, and adds "description" and
>> "type" fields, but drops requirements information and I'm not sure if it
>> can point to arbitrary objects the way entry_points.txt can.
>>
>> Anyway, entry_points.txt has been around enough years in the field that
>> the concept itself can't really be called "new" - it's actually quite
>> proven.  Checking
>> http://nullege.com/codes/search/pkg_resources.iter_entry_points/call , I
>> find 187 modules using just that one entry points API.
>>
>> Some projects do have more than one module loading plugins, but the
>> majority of those 187 appear to be different projects.
>>
>> Note that that's modules *loading plugins*, not plugins being
>> provided...  so the total number of PyPI projects using entry points in
>> some way is likely much higher, once you add in the plugins that these
>> 187 lookups are, well, looking up.
>>      
> setuptools entry points are just one way of doing plugins. There
> are other such systems that work well and which do not require
> any special administration or setup, simply because the application
> using the plugins defines the plugin protocol.
>    
Right, and those won't magically stop working if this proposal is 
implemented.

> Since you are into comparing numbers, you might want to count
> the number of Zope plugins that are available on PyPI and its plugin
> system has been around much longer than setuptools has been.
> I don't think that proves anything, though.
>
> I simply don't see a good reason to complicate the Python
> packaging system by trying to add a particular plugin support
> to it.
>
> Plugins are application scope features and should be treated
> as such.
>
>    
The fact is that entry points *are* widely used and solve a problem that 
you *can't* solve without some feature like this. The success of entry 
points demonstrates their utility (and you talk vaguely about 'problems' 
setuptools caused without any concrete examples - do you know of any 
*specific* difficulties with entry points?).

I doubt I will change your mind, but the bottom line is that if you 
don't like this feature you don't have to use it. For applications that 
want it (like the unittest plugin system) it will be *enormously* useful 
and *reduce* complexity for the user (by allowing simpler plugin 
management tools).

All the best,

Michael

-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (?BOGUS AGREEMENTS?) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.



From mal at egenix.com  Tue Aug  3 13:40:14 2010
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue, 03 Aug 2010 13:40:14 +0200
Subject: [Python-Dev] PEP 376 proposed changes for basic plugins support
In-Reply-To: <4C57F8CC.8000708@voidspace.org.uk>
References: <AANLkTinyjMkF2n91zS+48n6B_gkp9szW_bH0XJgTDh7D@mail.gmail.com>	<4C55FF0F.3010702@voidspace.org.uk>	<AANLkTim1af-zWEYF4U-vTr6d+8HkqFCycMVmQYsqpDcN@mail.gmail.com>	<4C5609A3.3090008@voidspace.org.uk>	<AANLkTimU-OUh8fzFoRvHMsQOqVa+jsFTfPyZKeY=heVg@mail.gmail.com>	<20100802010616.5FD133A4758@sparrow.telecommunity.com>	<AANLkTi=UDktBHXeQTU6_ouPk2sfnmhztMLY9yjzZJHP7@mail.gmail.com>	<4C56B846.9090009@egenix.com>	<20100802123145.2305.1286368223.divmod.xquotient.3@localhost.localdomain>	<4C56C57C.4000800@voidspace.org.uk>	<4C571E42.9040408@egenix.com>	<4C57247F.5060105@voidspace.org.uk>	<4C572C93.4040207@egenix.com>	<20100802213104.E6EFC3A479B@sparrow.telecommunity.com>	<4C57D317.8080707@egenix.com>
	<4C57F8CC.8000708@voidspace.org.uk>
Message-ID: <4C58001E.6060902@egenix.com>

Michael Foord wrote:
> On 03/08/2010 09:28, M.-A. Lemburg wrote:
>> P.J. Eby wrote:
>>   
>>> At 10:37 PM 8/2/2010 +0200, M.-A. Lemburg wrote:
>>>     
>>>> If that's the case, then it would be better to come up with an
>>>> idea of how to make access to that meta-data available in a less
>>>> I/O intense way, e.g. by having pip or other package managers update
>>>> a central SQLite database cache of the data found on disk.
>>>>        
>>> Don't forget system packaging tools like .deb, .rpm, etc., which do not
>>> generally take kindly to updating such things.  For better or worse, the
>>> filesystem *is* our "central database" these days.
>>>      
>> I don't think that's a problem: the SQLite database would be a cache
>> like e.g. a font cache or TCSH command cache, not a replacement of
>> the meta files stored in directories.
>>
>> Such a database would solve many things at once: faster access to
>> the meta-data of installed packages, fewer I/O calls during startup,
>> more flexible ways of doing queries on the meta-data, needed for
>> introspection and discovery, etc.
>>    
> 
> Sounds good as an "optional extra" (i.e. it should be safe to completely
> delete the cache file and still have everything work) to me. If the API
> for using the feature is worked out well first this could be done as a
> behind the scenes optimisation...

True, but is also allows more freedom in using existing resources:

The data put into the PLUGINS file is essentially not needed, since
this can be had from the meta-data (provided this gets some extra
fields for describing the plugin nature).

>>> Btw, while adding PLUGINS to PEP 376 is a new proposal, it's essentially
>>> another spelling of the existing entry_points.txt used by eggs; it
>>> changes the format to csv instead of .ini, and adds "description" and
>>> "type" fields, but drops requirements information and I'm not sure if it
>>> can point to arbitrary objects the way entry_points.txt can.
>>>
>>> Anyway, entry_points.txt has been around enough years in the field that
>>> the concept itself can't really be called "new" - it's actually quite
>>> proven.  Checking
>>> http://nullege.com/codes/search/pkg_resources.iter_entry_points/call , I
>>> find 187 modules using just that one entry points API.
>>>
>>> Some projects do have more than one module loading plugins, but the
>>> majority of those 187 appear to be different projects.
>>>
>>> Note that that's modules *loading plugins*, not plugins being
>>> provided...  so the total number of PyPI projects using entry points in
>>> some way is likely much higher, once you add in the plugins that these
>>> 187 lookups are, well, looking up.
>>>      
>> setuptools entry points are just one way of doing plugins. There
>> are other such systems that work well and which do not require
>> any special administration or setup, simply because the application
>> using the plugins defines the plugin protocol.
>>    
> Right, and those won't magically stop working if this proposal is
> implemented.

Right, but the proposal does add an extra burden on the package
manager tools and it codifies one specific way of implementing
plugins.

>> Since you are into comparing numbers, you might want to count
>> the number of Zope plugins that are available on PyPI and its plugin
>> system has been around much longer than setuptools has been.
>> I don't think that proves anything, though.
>>
>> I simply don't see a good reason to complicate the Python
>> packaging system by trying to add a particular plugin support
>> to it.
>>
>> Plugins are application scope features and should be treated
>> as such.
>>
>>    
> The fact is that entry points *are* widely used and solve a problem that
> you *can't* solve without some feature like this. The success of entry
> points demonstrates their utility (and you talk vaguely about 'problems'
> setuptools caused without any concrete examples - do you know of any
> *specific* difficulties with entry points?).

Not specific to entry points, but I do know a lot about of problems
that setuptools has introduced (and didn't want to start yet another
flame war based on these ;-).

> I doubt I will change your mind, but the bottom line is that if you
> don't like this feature you don't have to use it. For applications that
> want it (like the unittest plugin system) it will be *enormously* useful
> and *reduce* complexity for the user (by allowing simpler plugin
> management tools).

Sure and those tools can use such a system. No question there :-)

Maybe I just have to spell things out more clearly:

I support the idea of adding better query tools to the
installed package meta-data to make it easier to write plugin
systems or simplify existing ones.

I don't support the idea of using central configuration files
for plugins that span multiple applications (this reminds me
a lot of the early Windows win.ini file days and all the problems
this caused back then). It's better to have per application
configurations, implemented in a way that is suitable for
the application (e.g. some applications might want to store
plugin data in a database, provide GUI tools to enable/disable
plugins, etc.).

I also don't think it's necessary to complicate things to get this
extra functionality:

If you look at the proposal, it is really just about adding a
new data store to manage a certain package type called "plugins".
Next time around, someone will want to see support for "skins" or
"themes". Then perhaps identify "script" packages, or
"application" packages, or "namespace" packages, or "stubs", etc.
All this can be had by providing this kind of extra
meta-information in the already existing format.

If we add a new extra file to be managed by the package
managers every time someone comes up with a new use case,
we'd just clutter up the disk with more and more CSV file
extracts and make PEP 376 more and more complex.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Aug 03 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/
________________________________________________________________________

::: 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/

From steve at holdenweb.com  Tue Aug  3 13:44:14 2010
From: steve at holdenweb.com (Steve Holden)
Date: Tue, 03 Aug 2010 07:44:14 -0400
Subject: [Python-Dev] No response to posts
In-Reply-To: <87r5igrs5x.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <i32g9g$ouf$1@dough.gmane.org>	<4C54C5A4.6080409@netwok.org>	<AANLkTinpB7yVhMSQ=Q9hMCA+SnF4p+zNH98-GZd4ZP+w@mail.gmail.com>	<87r5ihm0k0.fsf@muni.brainbot.com>	<AANLkTikDM0nCVT1S9Jg-ZySTnysBvK0qk0Jpta8WZG82@mail.gmail.com>	<i372n8$2mg$1@dough.gmane.org>	<AANLkTinhe5xfO+sswME-HuKK_ecfrdrhaGhzKPXZFL-7@mail.gmail.com>	<i37imv$rli$1@dough.gmane.org>	<20100803012424.48807800@pitrou.net>	<i37kvt$18p$2@dough.gmane.org>	<4C5770D5.3050303@holdenweb.com>
	<87r5igrs5x.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <4C58010E.2000903@holdenweb.com>

On 8/3/2010 4:56 AM, Stephen J. Turnbull wrote:
> Steve Holden writes:
> 
>  > No, you don't, and the current discussion about how to ensure that bug
>  > reporters get at least the courtesy of a relatively quick reply is one
>  > of the most promising developments in building a welcoming community
>  > that I can remember.
> 
> C'mon Steve, it's not hard to see that's unfair.  Mark deserves to be
> complimented for the work he's doing, that side of your comment is
> perfectly fair, but you of all people should take care to recognize
> that python-dev is "welcoming people to the community" every day.
> 
[...]

Well if my response exaggerated the situation (which your statistics
seem to make clear it did) then I am very pleased to hear it, and
apologize unreservedly to anyone who feels slighted by my remarks.

I agree the developers as a whole do a magnificent (and largely unsung)
job, and I suspect that not many people realise what a struggle it has
been maintaining four separate branches in the run-up to 2.x
end-of-life. Now we are down to three, with presumably a much more
limited requirement to back-port changes, things should be a little less
stressful.

Particularly when the issue tracker works ...

>  > But let's not let that stop us trying to build a crew of
>  > ambassadors to take care of the more touchy-feely side of things as
>  > long as it operates to the language's ultimate benefit.
> 
> Nobody's interfering with that *at all*.  In fact, it's quite clear
> that everybody is happy with Mark's work, and wants him to continue.
> They just want him to give up on the idea that they're going to put in
> a lot more effort on resolving issues than they already do, and his
> claim that something's horribly wrong.  The numbers above show why.

I don't think anyone can criticize those whose first priority is the
development of code. That is, after all, why we are here.

I believe Mark's claim isn't that something's horribly wring with the
whole process. It seems to me that something would be *really* wrong if
nobody cared about the relatively few issues that had received no
response. The fact that Mark is on that case means that those who want
to shrug their shoulders about it can do so.

Python is "a broad church" and not everyone has an appetite for all
aspects of the development process. I see the current efforts to ensure
that new issues *all* receive an effective as complementary to the other
activities that have always taken place.

regards
 Steve
-- 
Steve Holden           +1 571 484 6266   +1 800 494 3119
DjangoCon US September 7-9, 2010    http://djangocon.us/
See Python Video!       http://python.mirocommunity.org/
Holden Web LLC                 http://www.holdenweb.com/

From solipsis at pitrou.net  Tue Aug  3 13:48:39 2010
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Tue, 3 Aug 2010 13:48:39 +0200
Subject: [Python-Dev] PEP 376 proposed changes for basic plugins support
References: <AANLkTinyjMkF2n91zS+48n6B_gkp9szW_bH0XJgTDh7D@mail.gmail.com>
	<4C55FF0F.3010702@voidspace.org.uk>
	<AANLkTim1af-zWEYF4U-vTr6d+8HkqFCycMVmQYsqpDcN@mail.gmail.com>
	<4C5609A3.3090008@voidspace.org.uk>
	<AANLkTimU-OUh8fzFoRvHMsQOqVa+jsFTfPyZKeY=heVg@mail.gmail.com>
	<20100802010616.5FD133A4758@sparrow.telecommunity.com>
	<AANLkTi=UDktBHXeQTU6_ouPk2sfnmhztMLY9yjzZJHP7@mail.gmail.com>
	<4C56B846.9090009@egenix.com>
	<20100802123145.2305.1286368223.divmod.xquotient.3@localhost.localdomain>
	<4C56C57C.4000800@voidspace.org.uk> <4C571E42.9040408@egenix.com>
	<4C57247F.5060105@voidspace.org.uk> <4C572C93.4040207@egenix.com>
	<20100802213104.E6EFC3A479B@sparrow.telecommunity.com>
	<4C57D317.8080707@egenix.com>
Message-ID: <20100803134839.28f39389@pitrou.net>

On Tue, 03 Aug 2010 10:28:07 +0200
"M.-A. Lemburg" <mal at egenix.com> wrote:
> > 
> > Don't forget system packaging tools like .deb, .rpm, etc., which do not
> > generally take kindly to updating such things.  For better or worse, the
> > filesystem *is* our "central database" these days.
> 
> I don't think that's a problem: the SQLite database would be a cache
> like e.g. a font cache or TCSH command cache, not a replacement of
> the meta files stored in directories.
> 
> Such a database would solve many things at once: faster access to
> the meta-data of installed packages, fewer I/O calls during startup,
> more flexible ways of doing queries on the meta-data, needed for
> introspection and discovery, etc.

If the cache can become stale because of system package management
tools, how do you avoid I/O calls while checking that the database is
fresh enough at startup?

Regards

Antoine.



From ncoghlan at gmail.com  Tue Aug  3 14:25:01 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 3 Aug 2010 22:25:01 +1000
Subject: [Python-Dev] co_firstlineno on decorated functions
In-Reply-To: <AANLkTi=7_nNcQ0bcWmtiy8E0-P8Z6doHT-A_wPSdiOum@mail.gmail.com>
References: <AANLkTinTg6TuJesKKKVCj-5RcLbit75JTtjrF794qUs-@mail.gmail.com>
	<AANLkTi=7_nNcQ0bcWmtiy8E0-P8Z6doHT-A_wPSdiOum@mail.gmail.com>
Message-ID: <AANLkTi=5xjs1GioFkw4iGATpZktiuZfh5dZN1fmgwHr8@mail.gmail.com>

On Tue, Aug 3, 2010 at 1:40 PM, Eli Bendersky <eliben at gmail.com> wrote:
> The first print out correctly specifies the line "def foo" is in. However,
> the second one points to the line with "@dummydecorator" instead of "def
> bar". [Python 2.6]
>
> The side-effects of this behavior can be easily seen in the output of
> modules like trace and profile. Would you say it's normal, or could this be
> considered a bug?

Since the decorator is as much a part of the function definition as
the def line is, I would say that it is correct (the name says
"firstlineno", not "deflineno"). inspect.getsource() and friends
actually rely on this behaviour, so changing it really isn't an
option.

However, that does mean *using* it as though it always points to the
def line is incorrect, suggesting there are related bugs in trace and
profile.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From ncoghlan at gmail.com  Tue Aug  3 14:44:08 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 3 Aug 2010 22:44:08 +1000
Subject: [Python-Dev] No response to posts
In-Reply-To: <87r5igrs5x.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <i32g9g$ouf$1@dough.gmane.org> <4C54C5A4.6080409@netwok.org>
	<AANLkTinpB7yVhMSQ=Q9hMCA+SnF4p+zNH98-GZd4ZP+w@mail.gmail.com>
	<87r5ihm0k0.fsf@muni.brainbot.com>
	<AANLkTikDM0nCVT1S9Jg-ZySTnysBvK0qk0Jpta8WZG82@mail.gmail.com>
	<i372n8$2mg$1@dough.gmane.org>
	<AANLkTinhe5xfO+sswME-HuKK_ecfrdrhaGhzKPXZFL-7@mail.gmail.com>
	<i37imv$rli$1@dough.gmane.org> <20100803012424.48807800@pitrou.net>
	<i37kvt$18p$2@dough.gmane.org> <4C5770D5.3050303@holdenweb.com>
	<87r5igrs5x.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <AANLkTimcN7BnBowidNZWmdmmnM2guUjYFaMbg=34gb05@mail.gmail.com>

On Tue, Aug 3, 2010 at 6:56 PM, Stephen J. Turnbull <stephen at xemacs.org> wrote:
> As Steven d'Aprano pointed out (admittedly with a bit of hyperbole) a
> very high percentage of issues (about 97%) do get some response, and
> nearly 87% of all issues ever submitted to Python have already been
> closed (based on the end-of-July tracker summary). ?Remember that many
> of those that are still open are open because nobody's willing to call
> them "walking dead" and close them as "unsalvagable." ?Any serious
> effort at triage by the people who would do the work to resolve them
> will surely result in a very large fraction closed with "wontfix",
> what is known as "a self-fulfilling prophecy". ?It's not clear that's
> a win; some users surely think so, others not.

There's at least one low priority bug that I submitted a couple of
years ago (doctest freaking out a bit if you use angle brackets in the
nominal filename) that is still open because the workaround of "well,
don't do that then" is so much easier than actually figuring out why
it is freaking out (my initial diagnosis pointed the finger at one of
the regular expressions in linecache, but I never actually nailed a
definitive culprit). Normal filenames don't usually contain angle
brackets, and in my case, it was a completely invented filename so I
could easily drop the angle brackets from the name.

It's a real bug though, so I'd prefer not to see it closed as "wontfix".

While that kind of bug is low on the effort/reward scale from an
absolute point of view, someone could still learn a lot on a personal
level from fixing it. Having it brought to my attention again recently
let me provide some better information on how to reproduce it by
hacking a bit on the current test suite, so someone looking to learn
more about the dev process could definitely work through distilling it
down into a dedicated test case and then figuring out how to make the
new test case pass.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From ronaldoussoren at mac.com  Tue Aug  3 14:46:05 2010
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Tue, 03 Aug 2010 14:46:05 +0200
Subject: [Python-Dev] PEP 376 proposed changes for basic plugins support
In-Reply-To: <AANLkTimU-OUh8fzFoRvHMsQOqVa+jsFTfPyZKeY=heVg@mail.gmail.com>
References: <AANLkTinyjMkF2n91zS+48n6B_gkp9szW_bH0XJgTDh7D@mail.gmail.com>
	<4C55FF0F.3010702@voidspace.org.uk>
	<AANLkTim1af-zWEYF4U-vTr6d+8HkqFCycMVmQYsqpDcN@mail.gmail.com>
	<4C5609A3.3090008@voidspace.org.uk>
	<AANLkTimU-OUh8fzFoRvHMsQOqVa+jsFTfPyZKeY=heVg@mail.gmail.com>
Message-ID: <406DAF34-6981-4FCE-A54A-AD02BB1B4433@mac.com>


On 2 Aug, 2010, at 2:03, Tarek Ziad? wrote:

> On Mon, Aug 2, 2010 at 1:56 AM, Michael Foord <fuzzyman at voidspace.org.uk> wrote:
>> On 02/08/2010 00:46, Tarek Ziad? wrote:
>>> 
>>> [snip...]
>>>> 
>>>> I don't think that unittest would use a distutils2 (or pkgutil) supplied
>>>> API
>>>> for activation.
>>>> 
>>> 
>>> But the discovery API you will use might just simply filter out
>>> disabled plugins.
>>> 
>> 
>> I did consider asking this but thought it was a silly question - there
>> *must* be an API to get all plugins otherwise applications couldn't activate
>> or deactivate them (or allow their users to do this) - and then how could
>> users activate a non-active plugin? (I guess there could be private APIs
>> that only distutils2 is supposed to use, or the script that you mentioned.)
> 
> yes, there will be a way to retrieve them all
> 
> ...
>> It sounds like it can fairly easily be bolted on as a new feature set later
>> *anyway*, so dropping it for now simplifies the initial implementation.
> 
> but then we would be back to the problem mentioned about entry points:
> installing projects can implicitly add a plugin and activate it, and break
> existing applications that iterate over entry points without further
> configuration. So being able to disable plugins from the beginning seems
> important to me

It should be the role of the application to manage which plugins are enabled and not the library.  The library can provide an API that applications can use to manage which plugins are activated, but the library should IMHO not force a specific scheme onto the application.

Keeping management outside of the libraries allows applications to provide their own mechanisms for it, such as the unittest2 configuration or even a configuration screen in a GUI application.   The latter is what's the most interesting to me, have a GUI application where users can optionally add functionality by adding a egg-file[*] to a plugin directory.  It would be nice if I could use the stdlib plugin API for that instead having to use my own inventions.

BTW. The spec seems to assume that the PLUGINS file is writeable, that needn't be true for example when packages are installed by a system tool or on multi-user systems where only sysadmins can install packages in a central site-packages location.

Ronald

[*] that is, a zipfile containing an installed distutils distribution
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3567 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100803/a270f07f/attachment.bin>

From solipsis at pitrou.net  Tue Aug  3 14:48:32 2010
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Tue, 3 Aug 2010 14:48:32 +0200
Subject: [Python-Dev] co_firstlineno on decorated functions
References: <AANLkTinTg6TuJesKKKVCj-5RcLbit75JTtjrF794qUs-@mail.gmail.com>
	<AANLkTi=7_nNcQ0bcWmtiy8E0-P8Z6doHT-A_wPSdiOum@mail.gmail.com>
	<AANLkTi=5xjs1GioFkw4iGATpZktiuZfh5dZN1fmgwHr8@mail.gmail.com>
Message-ID: <20100803144832.620b11ae@pitrou.net>

On Tue, 3 Aug 2010 22:25:01 +1000
Nick Coghlan <ncoghlan at gmail.com> wrote:
> On Tue, Aug 3, 2010 at 1:40 PM, Eli Bendersky <eliben at gmail.com> wrote:
> > The first print out correctly specifies the line "def foo" is in. However,
> > the second one points to the line with "@dummydecorator" instead of "def
> > bar". [Python 2.6]
> >
> > The side-effects of this behavior can be easily seen in the output of
> > modules like trace and profile. Would you say it's normal, or could this be
> > considered a bug?
> 
> Since the decorator is as much a part of the function definition as
> the def line is, I would say that it is correct (the name says
> "firstlineno", not "deflineno").

That's debatable. Since writing:

@b
def a():
    ...

is equivalent to:

def a():
    ...
a = b(a)

and in the latter case co_firstlineno points to the "def a()" line.

Furthermore, co_firstlineno is an attribute of the code object, not the
function object, so it shouldn't ideally depend on whether a decorator
was applied or not.

Regards

Antoine.



From ncoghlan at gmail.com  Tue Aug  3 15:05:53 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 3 Aug 2010 23:05:53 +1000
Subject: [Python-Dev] co_firstlineno on decorated functions
In-Reply-To: <20100803144832.620b11ae@pitrou.net>
References: <AANLkTinTg6TuJesKKKVCj-5RcLbit75JTtjrF794qUs-@mail.gmail.com>
	<AANLkTi=7_nNcQ0bcWmtiy8E0-P8Z6doHT-A_wPSdiOum@mail.gmail.com>
	<AANLkTi=5xjs1GioFkw4iGATpZktiuZfh5dZN1fmgwHr8@mail.gmail.com>
	<20100803144832.620b11ae@pitrou.net>
Message-ID: <AANLkTim_sOsL74krpF_Ze0gWcBM7jYUEpaL2_Ng2HK1N@mail.gmail.com>

On Tue, Aug 3, 2010 at 10:48 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> Furthermore, co_firstlineno is an attribute of the code object, not the
> function object, so it shouldn't ideally depend on whether a decorator
> was applied or not.

You cut the part about the inspect module (and no doubt other code)
relying on the current meaning, though. While I'd agree with you for a
clean slate definition, that's not what we're dealing with here:
"co_firstlineno" has an existing meaning, and it *isn't* "the line
containing the def keyword", it's "the first line of the function,
including any decorator lines". The decision could (and arguably
should) have gone the other way when decorator syntax was first added,
but changing our minds now would be making the situation worse rather
than better.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From ysj.ray at gmail.com  Tue Aug  3 07:01:46 2010
From: ysj.ray at gmail.com (Ray Allen)
Date: Tue, 3 Aug 2010 13:01:46 +0800
Subject: [Python-Dev] Tracker status
In-Reply-To: <AANLkTimO9mYR_u3ghrZNGmPP6puqiP-g7OW9g92c4rjV@mail.gmail.com>
References: <AANLkTi=fcQJP6SuNSz35+HpCzeDVY8bYEs2VtLS2Mq2z@mail.gmail.com>
	<AANLkTi=a5KhS-X_Ec=2pUbzH71MSNgfrkeYT=qUEehto@mail.gmail.com>
	<AANLkTimO9mYR_u3ghrZNGmPP6puqiP-g7OW9g92c4rjV@mail.gmail.com>
Message-ID: <AANLkTinPcYfFsHrnKsYZwV18ywESMydDSzKrYv=WF2fG@mail.gmail.com>

Is the tracker OK now?

-- 
Ray Allen
Best wishes!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100803/4499f1b2/attachment.html>

From dirkjan at ochtman.nl  Tue Aug  3 15:48:48 2010
From: dirkjan at ochtman.nl (Dirkjan Ochtman)
Date: Tue, 3 Aug 2010 15:48:48 +0200
Subject: [Python-Dev] Tracker status
In-Reply-To: <AANLkTinPcYfFsHrnKsYZwV18ywESMydDSzKrYv=WF2fG@mail.gmail.com>
References: <AANLkTi=fcQJP6SuNSz35+HpCzeDVY8bYEs2VtLS2Mq2z@mail.gmail.com> 
	<AANLkTi=a5KhS-X_Ec=2pUbzH71MSNgfrkeYT=qUEehto@mail.gmail.com> 
	<AANLkTimO9mYR_u3ghrZNGmPP6puqiP-g7OW9g92c4rjV@mail.gmail.com> 
	<AANLkTinPcYfFsHrnKsYZwV18ywESMydDSzKrYv=WF2fG@mail.gmail.com>
Message-ID: <AANLkTinuS5xaHaJzv4RaxcKPAqVAy-bOrzVVhO7isxqd@mail.gmail.com>

On Tue, Aug 3, 2010 at 07:01, Ray Allen <ysj.ray at gmail.com> wrote:
> Is the tracker OK now?

Works for me.

Cheers,

Dirkjan

From fdrake at acm.org  Tue Aug  3 15:50:16 2010
From: fdrake at acm.org (Fred Drake)
Date: Tue, 3 Aug 2010 09:50:16 -0400
Subject: [Python-Dev] Tracker status
In-Reply-To: <AANLkTinPcYfFsHrnKsYZwV18ywESMydDSzKrYv=WF2fG@mail.gmail.com>
References: <AANLkTi=fcQJP6SuNSz35+HpCzeDVY8bYEs2VtLS2Mq2z@mail.gmail.com> 
	<AANLkTi=a5KhS-X_Ec=2pUbzH71MSNgfrkeYT=qUEehto@mail.gmail.com> 
	<AANLkTimO9mYR_u3ghrZNGmPP6puqiP-g7OW9g92c4rjV@mail.gmail.com> 
	<AANLkTinPcYfFsHrnKsYZwV18ywESMydDSzKrYv=WF2fG@mail.gmail.com>
Message-ID: <AANLkTikoT-WLpsrmwKSRGZ7C1fx-uKsnGKGEkOfFE7w+@mail.gmail.com>

On Tue, Aug 3, 2010 at 1:01 AM, Ray Allen <ysj.ray at gmail.com> wrote:
> Is the tracker OK now?

It's working for me.


? -Fred

--
Fred L. Drake, Jr.? ? <fdrake at gmail.com>
"A storm broke loose in my mind."? --Albert Einstein

From florent.xicluna at gmail.com  Tue Aug  3 15:59:50 2010
From: florent.xicluna at gmail.com (Florent Xicluna)
Date: Tue, 3 Aug 2010 15:59:50 +0200
Subject: [Python-Dev] Tracker status
In-Reply-To: <AANLkTikoT-WLpsrmwKSRGZ7C1fx-uKsnGKGEkOfFE7w+@mail.gmail.com>
References: <AANLkTi=fcQJP6SuNSz35+HpCzeDVY8bYEs2VtLS2Mq2z@mail.gmail.com>
	<AANLkTi=a5KhS-X_Ec=2pUbzH71MSNgfrkeYT=qUEehto@mail.gmail.com>
	<AANLkTimO9mYR_u3ghrZNGmPP6puqiP-g7OW9g92c4rjV@mail.gmail.com>
	<AANLkTinPcYfFsHrnKsYZwV18ywESMydDSzKrYv=WF2fG@mail.gmail.com>
	<AANLkTikoT-WLpsrmwKSRGZ7C1fx-uKsnGKGEkOfFE7w+@mail.gmail.com>
Message-ID: <AANLkTinGB+1VNRGi3suxuMxS_n+cALiUBvGO_LxJsgR2@mail.gmail.com>

There's no new issue posted this morning.
I tried to post an issue, and an error occurred on submit.

So...

-- 
Florent


2010/8/3 Fred Drake <fdrake at acm.org>

> On Tue, Aug 3, 2010 at 1:01 AM, Ray Allen <ysj.ray at gmail.com> wrote:
> > Is the tracker OK now?
>
> It's working for me.
>
>
>   -Fred
>
> --
> Fred L. Drake, Jr.    <fdrake at gmail.com>
> "A storm broke loose in my mind."  --Albert Einstein
> _______________________________________________
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100803/38580b23/attachment.html>

From stephen at xemacs.org  Tue Aug  3 16:05:31 2010
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Tue, 03 Aug 2010 23:05:31 +0900
Subject: [Python-Dev] No response to posts
In-Reply-To: <4C58010E.2000903@holdenweb.com>
References: <i32g9g$ouf$1@dough.gmane.org> <4C54C5A4.6080409@netwok.org>
	<AANLkTinpB7yVhMSQ=Q9hMCA+SnF4p+zNH98-GZd4ZP+w@mail.gmail.com>
	<87r5ihm0k0.fsf@muni.brainbot.com>
	<AANLkTikDM0nCVT1S9Jg-ZySTnysBvK0qk0Jpta8WZG82@mail.gmail.com>
	<i372n8$2mg$1@dough.gmane.org>
	<AANLkTinhe5xfO+sswME-HuKK_ecfrdrhaGhzKPXZFL-7@mail.gmail.com>
	<i37imv$rli$1@dough.gmane.org> <20100803012424.48807800@pitrou.net>
	<i37kvt$18p$2@dough.gmane.org> <4C5770D5.3050303@holdenweb.com>
	<87r5igrs5x.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4C58010E.2000903@holdenweb.com>
Message-ID: <87mxt3sses.fsf@uwakimon.sk.tsukuba.ac.jp>

Steve, thanks for your care-full reply.

Steve Holden writes:

 > Particularly when the issue tracker works ...

Well, sometimes it's down.  <shrug />  But Roundup is more flexible as
a database engine than a lot of people realize.  Better docs would
help, I'm sure, but we can also create new standard queries quite
easily.  While it's not really possible to get good statistics on
time-to-close, for example, we can do a pretty good job of identifying
"ignored" issues, and we can target reducing the count to some extent.

 > It seems to me that something would be *really* wrong if
 > nobody cared about the relatively few issues that had received no
 > response.

Phrased as "care about", that's a straw man.  Pretty much everybody
cares about those issues.  Phrased as "care for", well, now we've
found the friction, I suspect.  Applying real TLC to many of the
hangfire issues is going to require highlevel skills and/or lots of
time, resources that are scarce around here (because they're being
applied to other important tasks).

 > The fact that Mark is on that case means that those who want
 > to shrug their shoulders about it can do so.

Indeed, that's the way I feel about it.  But Mark clearly doesn't
think he alone is enough.  There's a genuine difference of opinion
here somewhere, even if I've misrepresented Mark's opinion.

Maybe it would help if we scheduled a bug day, and try to make sure
that a couple senior devs rendezvous with Mark so he can advocate some
of the issues that bother him the most, and he can get a look at the
issue resolution process in action.

 > I see the current efforts to ensure that new issues *all* receive
 > an effective as complementary to the other activities that have
 > always taken place.

Again, there's friction here.  Somebody said that it's really no help
if the acknowledgment is automatic, and that's true.  The reply was
that a polite response from a human isn't necessarily going to be much
better unless there's real help in it, and that's true too.  As I
understand Mark, that's a lot of his frustration; he doesn't yet know
enough to be of genuine help in most of the issues he handles, so he
has to be satisfied with either dropping it on the floor again, or
sending out an embarrassing "Hi, I'm from the Python triage team, and
I'm sorry to tell you that after five years of dead silence, we still
have nothing to say."  Anyway, I know *I* find that frustrating when I
have to do it!

Where do we find the resources to provide that "real help"?  Again,
maybe one bug day to show what can be done, and then more or less
regularly-scheduled bug days to keep up the momentum?


From guido at python.org  Tue Aug  3 16:14:42 2010
From: guido at python.org (Guido van Rossum)
Date: Tue, 3 Aug 2010 07:14:42 -0700
Subject: [Python-Dev] co_firstlineno on decorated functions
In-Reply-To: <AANLkTim_sOsL74krpF_Ze0gWcBM7jYUEpaL2_Ng2HK1N@mail.gmail.com>
References: <AANLkTinTg6TuJesKKKVCj-5RcLbit75JTtjrF794qUs-@mail.gmail.com> 
	<AANLkTi=7_nNcQ0bcWmtiy8E0-P8Z6doHT-A_wPSdiOum@mail.gmail.com> 
	<AANLkTi=5xjs1GioFkw4iGATpZktiuZfh5dZN1fmgwHr8@mail.gmail.com> 
	<20100803144832.620b11ae@pitrou.net>
	<AANLkTim_sOsL74krpF_Ze0gWcBM7jYUEpaL2_Ng2HK1N@mail.gmail.com>
Message-ID: <AANLkTinnpOOi9tLHvBetR1i6jS-XOUFiUA=QxVW-9DQk@mail.gmail.com>

On Tue, Aug 3, 2010 at 6:05 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On Tue, Aug 3, 2010 at 10:48 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
>> Furthermore, co_firstlineno is an attribute of the code object, not the
>> function object, so it shouldn't ideally depend on whether a decorator
>> was applied or not.
>
> You cut the part about the inspect module (and no doubt other code)
> relying on the current meaning, though. While I'd agree with you for a
> clean slate definition, that's not what we're dealing with here:
> "co_firstlineno" has an existing meaning, and it *isn't* "the line
> containing the def keyword", it's "the first line of the function,
> including any decorator lines". The decision could (and arguably
> should) have gone the other way when decorator syntax was first added,
> but changing our minds now would be making the situation worse rather
> than better.

What are the use cases for co_firstlineno? Even if it is for
displaying the source code, I can find virtue for both sides of this
argument.

-- 
--Guido van Rossum (python.org/~guido)

From cournape at gmail.com  Tue Aug  3 16:19:56 2010
From: cournape at gmail.com (David Cournapeau)
Date: Tue, 3 Aug 2010 23:19:56 +0900
Subject: [Python-Dev] PEP 376 proposed changes for basic plugins support
In-Reply-To: <20100803134839.28f39389@pitrou.net>
References: <AANLkTinyjMkF2n91zS+48n6B_gkp9szW_bH0XJgTDh7D@mail.gmail.com>
	<4C55FF0F.3010702@voidspace.org.uk>
	<AANLkTim1af-zWEYF4U-vTr6d+8HkqFCycMVmQYsqpDcN@mail.gmail.com>
	<4C5609A3.3090008@voidspace.org.uk>
	<AANLkTimU-OUh8fzFoRvHMsQOqVa+jsFTfPyZKeY=heVg@mail.gmail.com>
	<20100802010616.5FD133A4758@sparrow.telecommunity.com>
	<AANLkTi=UDktBHXeQTU6_ouPk2sfnmhztMLY9yjzZJHP7@mail.gmail.com>
	<4C56B846.9090009@egenix.com>
	<20100802123145.2305.1286368223.divmod.xquotient.3@localhost.localdomain>
	<4C56C57C.4000800@voidspace.org.uk> <4C571E42.9040408@egenix.com>
	<4C57247F.5060105@voidspace.org.uk> <4C572C93.4040207@egenix.com>
	<20100802213104.E6EFC3A479B@sparrow.telecommunity.com>
	<4C57D317.8080707@egenix.com> <20100803134839.28f39389@pitrou.net>
Message-ID: <AANLkTinPG=HBL00BLxLb+bPjKumZTpL2xRjrjKf2qeea@mail.gmail.com>

On Tue, Aug 3, 2010 at 8:48 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Tue, 03 Aug 2010 10:28:07 +0200
> "M.-A. Lemburg" <mal at egenix.com> wrote:
>> >
>> > Don't forget system packaging tools like .deb, .rpm, etc., which do not
>> > generally take kindly to updating such things. ?For better or worse, the
>> > filesystem *is* our "central database" these days.
>>
>> I don't think that's a problem: the SQLite database would be a cache
>> like e.g. a font cache or TCSH command cache, not a replacement of
>> the meta files stored in directories.
>>
>> Such a database would solve many things at once: faster access to
>> the meta-data of installed packages, fewer I/O calls during startup,
>> more flexible ways of doing queries on the meta-data, needed for
>> introspection and discovery, etc.
>
> If the cache can become stale because of system package management
> tools, how do you avoid I/O calls while checking that the database is
> fresh enough at startup?

There is a tension between the two approaches: either you want
"auto-discovery", or you want a system with explicit registration and
only the registered plugins would be visible to the system.

System-wise, I much prefer the later, and auto-discovery should be
left at the application discretion IMO. A library to deal with this at
the *app* level may be fine. But the current system of loading
packages and co is already complex enough in python that anything that
complexify at the system (interpreter) level sounds like a bad idea.

David

From solipsis at pitrou.net  Tue Aug  3 16:28:45 2010
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Tue, 03 Aug 2010 16:28:45 +0200
Subject: [Python-Dev] PEP 376 proposed changes for basic plugins support
In-Reply-To: <AANLkTinPG=HBL00BLxLb+bPjKumZTpL2xRjrjKf2qeea@mail.gmail.com>
References: <AANLkTinyjMkF2n91zS+48n6B_gkp9szW_bH0XJgTDh7D@mail.gmail.com>
	<4C55FF0F.3010702@voidspace.org.uk>
	<AANLkTim1af-zWEYF4U-vTr6d+8HkqFCycMVmQYsqpDcN@mail.gmail.com>
	<4C5609A3.3090008@voidspace.org.uk>
	<AANLkTimU-OUh8fzFoRvHMsQOqVa+jsFTfPyZKeY=heVg@mail.gmail.com>
	<20100802010616.5FD133A4758@sparrow.telecommunity.com>
	<AANLkTi=UDktBHXeQTU6_ouPk2sfnmhztMLY9yjzZJHP7@mail.gmail.com>
	<4C56B846.9090009@egenix.com>
	<20100802123145.2305.1286368223.divmod.xquotient.3@localhost.localdomain>
	<4C56C57C.4000800@voidspace.org.uk> <4C571E42.9040408@egenix.com>
	<4C57247F.5060105@voidspace.org.uk> <4C572C93.4040207@egenix.com>
	<20100802213104.E6EFC3A479B@sparrow.telecommunity.com>
	<4C57D317.8080707@egenix.com> <20100803134839.28f39389@pitrou.net>
	<AANLkTinPG=HBL00BLxLb+bPjKumZTpL2xRjrjKf2qeea@mail.gmail.com>
Message-ID: <1280845725.3170.2.camel@localhost.localdomain>


> There is a tension between the two approaches: either you want
> "auto-discovery", or you want a system with explicit registration and
> only the registered plugins would be visible to the system.

I think both are necessary. A discovery API should be available, but the
library or application should be free to do whatever it wants with the
discovered plugins - enable them automatically, present them to the
user, or nothing.

(a GUI application, for example, needs to be able to display a list of
available plugins, with checkboxes to enable or disable each of them. It
is not reasonable to expect the user to type the plugin name in a
textbox)

Regards

Antoine.



From pje at telecommunity.com  Tue Aug  3 16:32:29 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Tue, 03 Aug 2010 10:32:29 -0400
Subject: [Python-Dev] PEP 376 proposed changes for basic plugins support
In-Reply-To: <4C57D317.8080707@egenix.com>
References: <AANLkTinyjMkF2n91zS+48n6B_gkp9szW_bH0XJgTDh7D@mail.gmail.com>
	<4C55FF0F.3010702@voidspace.org.uk>
	<AANLkTim1af-zWEYF4U-vTr6d+8HkqFCycMVmQYsqpDcN@mail.gmail.com>
	<4C5609A3.3090008@voidspace.org.uk>
	<AANLkTimU-OUh8fzFoRvHMsQOqVa+jsFTfPyZKeY=heVg@mail.gmail.com>
	<20100802010616.5FD133A4758@sparrow.telecommunity.com>
	<AANLkTi=UDktBHXeQTU6_ouPk2sfnmhztMLY9yjzZJHP7@mail.gmail.com>
	<4C56B846.9090009@egenix.com>
	<20100802123145.2305.1286368223.divmod.xquotient.3@localhost.localdomain>
	<4C56C57C.4000800@voidspace.org.uk> <4C571E42.9040408@egenix.com>
	<4C57247F.5060105@voidspace.org.uk> <4C572C93.4040207@egenix.com>
	<20100802213104.E6EFC3A479B@sparrow.telecommunity.com>
	<4C57D317.8080707@egenix.com>
Message-ID: <20100803143229.CB4B83A4743@sparrow.telecommunity.com>

At 10:28 AM 8/3/2010 +0200, M.-A. Lemburg wrote:
>Since you are into comparing numbers, you might want to count
>the number of Zope plugins that are available on PyPI and its plugin
>system has been around much longer than setuptools has been.
>I don't think that proves anything, though.

Actually, some of the ones I found in the search using entry points 
*were* Zope, which, as I mentioned before, is increasingly moving 
away from the old approach in favor of entry points.

In any case, I am not advocating *setuptools* -- I'm advocating that 
if PEP 376 expands to add plugin support, that it do so with a file 
format and associated API based on that of entry points, so as to 
make migration of those ~187 modules and their associated plugins to 
distutils2 a little easier.

In other words, I'm trying to make it easier for people to move OFF 
of setuptools.

Crazy, I know, but there you go.  ;-)


From solipsis at pitrou.net  Tue Aug  3 16:35:01 2010
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Tue, 3 Aug 2010 16:35:01 +0200
Subject: [Python-Dev] Tracker status
References: <AANLkTi=fcQJP6SuNSz35+HpCzeDVY8bYEs2VtLS2Mq2z@mail.gmail.com>
	<AANLkTi=a5KhS-X_Ec=2pUbzH71MSNgfrkeYT=qUEehto@mail.gmail.com>
	<AANLkTimO9mYR_u3ghrZNGmPP6puqiP-g7OW9g92c4rjV@mail.gmail.com>
	<AANLkTinPcYfFsHrnKsYZwV18ywESMydDSzKrYv=WF2fG@mail.gmail.com>
	<AANLkTikoT-WLpsrmwKSRGZ7C1fx-uKsnGKGEkOfFE7w+@mail.gmail.com>
	<AANLkTinGB+1VNRGi3suxuMxS_n+cALiUBvGO_LxJsgR2@mail.gmail.com>
Message-ID: <20100803163501.0e53e1f2@pitrou.net>


Apparently you are not the only one experiencing it.
On #python-dev we get such notifications:

<CIA-31> alanwilter roundup * #9485/signal.signal/signal.alarm not
working as expected: [new] I have this example code to illustrate a
problem I am ...
<CIA-31> alanwilter roundup * #9486/signal.signal/signal.alarm not
working as expected: [new] I have this example code to illustrate a
problem I am ... <fdrake> gutworth: Too late.  tarek is lost to us.
<CIA-31> alanwilter roundup * #9487/signal.signal/signal.alarm not
working as expected: [new] I have this example code to illustrate a
problem I am ...
<CIA-31> alanwilter roundup * #9488/signal.signal/signal.alarm not
working as expected: [new] I have this example code to illustrate a
problem I am ...

But the relevant bug entries don't exist.

Regards

Antoine.



On Tue, 3 Aug 2010 15:59:50 +0200
Florent Xicluna <florent.xicluna at gmail.com> wrote:

> There's no new issue posted this morning.
> I tried to post an issue, and an error occurred on submit.
> 
> So...
> 
> -- 
> Florent
> 
> 
> 2010/8/3 Fred Drake <fdrake at acm.org>
> 
> > On Tue, Aug 3, 2010 at 1:01 AM, Ray Allen <ysj.ray at gmail.com> wrote:
> > > Is the tracker OK now?
> >
> > It's working for me.
> >
> >
> >   -Fred
> >
> > --
> > Fred L. Drake, Jr.    <fdrake at gmail.com>
> > "A storm broke loose in my mind."  --Albert Einstein
> > _______________________________________________
> >
> 



From fuzzyman at voidspace.org.uk  Tue Aug  3 16:35:30 2010
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Tue, 03 Aug 2010 15:35:30 +0100
Subject: [Python-Dev] PEP 376 proposed changes for basic plugins support
In-Reply-To: <AANLkTinPG=HBL00BLxLb+bPjKumZTpL2xRjrjKf2qeea@mail.gmail.com>
References: <AANLkTinyjMkF2n91zS+48n6B_gkp9szW_bH0XJgTDh7D@mail.gmail.com>	<4C55FF0F.3010702@voidspace.org.uk>	<AANLkTim1af-zWEYF4U-vTr6d+8HkqFCycMVmQYsqpDcN@mail.gmail.com>	<4C5609A3.3090008@voidspace.org.uk>	<AANLkTimU-OUh8fzFoRvHMsQOqVa+jsFTfPyZKeY=heVg@mail.gmail.com>	<20100802010616.5FD133A4758@sparrow.telecommunity.com>	<AANLkTi=UDktBHXeQTU6_ouPk2sfnmhztMLY9yjzZJHP7@mail.gmail.com>	<4C56B846.9090009@egenix.com>	<20100802123145.2305.1286368223.divmod.xquotient.3@localhost.localdomain>	<4C56C57C.4000800@voidspace.org.uk>
	<4C571E42.9040408@egenix.com>	<4C57247F.5060105@voidspace.org.uk>
	<4C572C93.4040207@egenix.com>	<20100802213104.E6EFC3A479B@sparrow.telecommunity.com>	<4C57D317.8080707@egenix.com>
	<20100803134839.28f39389@pitrou.net>
	<AANLkTinPG=HBL00BLxLb+bPjKumZTpL2xRjrjKf2qeea@mail.gmail.com>
Message-ID: <4C582932.1010309@voidspace.org.uk>

On 03/08/2010 15:19, David Cournapeau wrote:
> On Tue, Aug 3, 2010 at 8:48 PM, Antoine Pitrou<solipsis at pitrou.net>  wrote:
>    
>> On Tue, 03 Aug 2010 10:28:07 +0200
>> "M.-A. Lemburg"<mal at egenix.com>  wrote:
>>      
>>>> Don't forget system packaging tools like .deb, .rpm, etc., which do not
>>>> generally take kindly to updating such things.  For better or worse, the
>>>> filesystem *is* our "central database" these days.
>>>>          
>>> I don't think that's a problem: the SQLite database would be a cache
>>> like e.g. a font cache or TCSH command cache, not a replacement of
>>> the meta files stored in directories.
>>>
>>> Such a database would solve many things at once: faster access to
>>> the meta-data of installed packages, fewer I/O calls during startup,
>>> more flexible ways of doing queries on the meta-data, needed for
>>> introspection and discovery, etc.
>>>        
>> If the cache can become stale because of system package management
>> tools, how do you avoid I/O calls while checking that the database is
>> fresh enough at startup?
>>      
> There is a tension between the two approaches: either you want
> "auto-discovery", or you want a system with explicit registration and
> only the registered plugins would be visible to the system.
>
>    

Not true. Auto-discovery provides an API for applications to tell users 
which plugins are *available* whilst still allowing the app to decide 
which are active / enabled. It still leaves full control in the hands of 
the application.

It also allows the user / sysadmin to use their standard tools, whether 
that be disutils2 or package managers, to install the plugins instead of 
requiring ad-hoc approaches like "drop this file in this location".

All the best,

Michael Foord

> System-wise, I much prefer the later, and auto-discovery should be
> left at the application discretion IMO. A library to deal with this at
> the *app* level may be fine. But the current system of loading
> packages and co is already complex enough in python that anything that
> complexify at the system (interpreter) level sounds like a bad idea.
>
> David
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at 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/


From pje at telecommunity.com  Tue Aug  3 16:45:35 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Tue, 03 Aug 2010 10:45:35 -0400
Subject: [Python-Dev] PEP 376 proposed changes for basic plugins support
In-Reply-To: <4C58001E.6060902@egenix.com>
References: <AANLkTinyjMkF2n91zS+48n6B_gkp9szW_bH0XJgTDh7D@mail.gmail.com>
	<4C55FF0F.3010702@voidspace.org.uk>
	<AANLkTim1af-zWEYF4U-vTr6d+8HkqFCycMVmQYsqpDcN@mail.gmail.com>
	<4C5609A3.3090008@voidspace.org.uk>
	<AANLkTimU-OUh8fzFoRvHMsQOqVa+jsFTfPyZKeY=heVg@mail.gmail.com>
	<20100802010616.5FD133A4758@sparrow.telecommunity.com>
	<AANLkTi=UDktBHXeQTU6_ouPk2sfnmhztMLY9yjzZJHP7@mail.gmail.com>
	<4C56B846.9090009@egenix.com>
	<20100802123145.2305.1286368223.divmod.xquotient.3@localhost.localdomain>
	<4C56C57C.4000800@voidspace.org.uk> <4C571E42.9040408@egenix.com>
	<4C57247F.5060105@voidspace.org.uk> <4C572C93.4040207@egenix.com>
	<20100802213104.E6EFC3A479B@sparrow.telecommunity.com>
	<4C57D317.8080707@egenix.com> <4C57F8CC.8000708@voidspace.org.uk>
	<4C58001E.6060902@egenix.com>
Message-ID: <20100803144534.7E0403A4743@sparrow.telecommunity.com>

At 01:40 PM 8/3/2010 +0200, M.-A. Lemburg wrote:
>If you look at the proposal, it is really just about adding a
>new data store to manage a certain package type called "plugins".
>Next time around, someone will want to see support for "skins" or
>"themes". Then perhaps identify "script" packages, or
>"application" packages, or "namespace" packages, or "stubs", etc.
>All this can be had by providing this kind of extra
>meta-information in the already existing format.

If by "existing format", you mean "entry points", then yes, that is 
true.  ;-)  They are used today for most of the things you listed; 
anything that's an importable Python object (module, class, function, 
package, constant, global) can be listed as an entry point belonging 
to a named group.  Heck, the first code sample on Nullege for 
iter_entry_points is some package called Apydia loading an entry 
point group called "apydia.themes"!

Seriously, though, PEP 376 is just setuptools' egg-info under a 
different name with uninstall support added.  And egg-info was 
designed to be able to hold all those things you're talking 
about.  The EggTranslations project, for example, defines 
i18n-support files that can be placed under egg-info, and provides 
its own APIs for looking those things up.  Applications using 
EggTranslations can not only have their own translations shipped as 
plugins, but plugins can provide translations for other plugins of 
the same application.  (I believe it also supports providing other 
i18n resources such as icons as well.)

So, it isn't actually necessary for the stdlib to provide any 
particular support for specific kinds of metadata within PEP 376, as 
long as the PEP 376 API supports finding packages with metadata files 
of a particular name.  (EggTranslations uses similar APIs provided by 
pkg_resources.)

However, since Tarek proposed adding a stdlib-supported plugins 
feature, I am suggesting it adopt the entry_points.txt file name and 
format, to avoid unnecessary API fragmentation.


>If we add a new extra file to be managed by the package
>managers every time someone comes up with a new use case,
>we'd just clutter up the disk with more and more CSV file
>extracts and make PEP 376 more and more complex.

The setuptools egg-info convention is not to create files that don't 
contain any useful content, so that their presence or absence conveys 
information.  If that convention is continued in PEP 376, features 
that aren't used won't take up any disk space.

As for cluttering the PEP, IMO any metadata files that aren't part of 
the "installation database" feature should probably have their own PEP.


From draghuram at gmail.com  Tue Aug  3 17:05:08 2010
From: draghuram at gmail.com (Raghuram Devarakonda)
Date: Tue, 3 Aug 2010 11:05:08 -0400
Subject: [Python-Dev] co_firstlineno on decorated functions
In-Reply-To: <AANLkTinnpOOi9tLHvBetR1i6jS-XOUFiUA=QxVW-9DQk@mail.gmail.com>
References: <AANLkTinTg6TuJesKKKVCj-5RcLbit75JTtjrF794qUs-@mail.gmail.com> 
	<AANLkTi=7_nNcQ0bcWmtiy8E0-P8Z6doHT-A_wPSdiOum@mail.gmail.com> 
	<AANLkTi=5xjs1GioFkw4iGATpZktiuZfh5dZN1fmgwHr8@mail.gmail.com> 
	<20100803144832.620b11ae@pitrou.net>
	<AANLkTim_sOsL74krpF_Ze0gWcBM7jYUEpaL2_Ng2HK1N@mail.gmail.com> 
	<AANLkTinnpOOi9tLHvBetR1i6jS-XOUFiUA=QxVW-9DQk@mail.gmail.com>
Message-ID: <AANLkTimTuQxhFk-e4rztKwKUdqM0b2tQzdEpaBPxR318@mail.gmail.com>

On Tue, Aug 3, 2010 at 10:14 AM, Guido van Rossum <guido at python.org> wrote:

> What are the use cases for co_firstlineno? Even if it is for
> displaying the source code, I can find virtue for both sides of this
> argument.

nose uses co_firstlineno to determine order of the test functions and
decorating a test function can change such order. To keep the
ordering, it provides nose.tools.make_decorator() which explicitly
keeps the line number of the original function. Check the following
thread for a discussion in this regard:

http://groups.google.com/group/nose-users/browse_thread/thread/3e354cbb5b1fac6/107429c5abbf2e59

Thanks,
Raghu

From solipsis at pitrou.net  Tue Aug  3 17:19:50 2010
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Tue, 03 Aug 2010 17:19:50 +0200
Subject: [Python-Dev] co_firstlineno on decorated functions
In-Reply-To: <AANLkTimTuQxhFk-e4rztKwKUdqM0b2tQzdEpaBPxR318@mail.gmail.com>
References: <AANLkTinTg6TuJesKKKVCj-5RcLbit75JTtjrF794qUs-@mail.gmail.com>
	<AANLkTi=7_nNcQ0bcWmtiy8E0-P8Z6doHT-A_wPSdiOum@mail.gmail.com>
	<AANLkTi=5xjs1GioFkw4iGATpZktiuZfh5dZN1fmgwHr8@mail.gmail.com>
	<20100803144832.620b11ae@pitrou.net>
	<AANLkTim_sOsL74krpF_Ze0gWcBM7jYUEpaL2_Ng2HK1N@mail.gmail.com>
	<AANLkTinnpOOi9tLHvBetR1i6jS-XOUFiUA=QxVW-9DQk@mail.gmail.com>
	<AANLkTimTuQxhFk-e4rztKwKUdqM0b2tQzdEpaBPxR318@mail.gmail.com>
Message-ID: <1280848790.3170.4.camel@localhost.localdomain>

Le mardi 03 ao?t 2010 ? 11:05 -0400, Raghuram Devarakonda a ?crit :
> On Tue, Aug 3, 2010 at 10:14 AM, Guido van Rossum <guido at python.org> wrote:
> 
> > What are the use cases for co_firstlineno? Even if it is for
> > displaying the source code, I can find virtue for both sides of this
> > argument.
> 
> nose uses co_firstlineno to determine order of the test functions and
> decorating a test function can change such order. To keep the
> ordering, it provides nose.tools.make_decorator() which explicitly
> keeps the line number of the original function. Check the following
> thread for a discussion in this regard:

That's pretty much orthogonal, though. We're talking about the case of a
decorator which returns the original function object (and therefore
doesn't change co_firstlineno).

Anyway, when co_firstlineno is used for ordering purposes, it doesn't
matter whether some values are offset by one when a decorator is
applied.

Regards

Antoine.



From cournape at gmail.com  Tue Aug  3 17:24:26 2010
From: cournape at gmail.com (David Cournapeau)
Date: Wed, 4 Aug 2010 00:24:26 +0900
Subject: [Python-Dev] PEP 376 proposed changes for basic plugins support
In-Reply-To: <4C582932.1010309@voidspace.org.uk>
References: <AANLkTinyjMkF2n91zS+48n6B_gkp9szW_bH0XJgTDh7D@mail.gmail.com>
	<4C55FF0F.3010702@voidspace.org.uk>
	<AANLkTim1af-zWEYF4U-vTr6d+8HkqFCycMVmQYsqpDcN@mail.gmail.com>
	<4C5609A3.3090008@voidspace.org.uk>
	<AANLkTimU-OUh8fzFoRvHMsQOqVa+jsFTfPyZKeY=heVg@mail.gmail.com>
	<20100802010616.5FD133A4758@sparrow.telecommunity.com>
	<AANLkTi=UDktBHXeQTU6_ouPk2sfnmhztMLY9yjzZJHP7@mail.gmail.com>
	<4C56B846.9090009@egenix.com>
	<20100802123145.2305.1286368223.divmod.xquotient.3@localhost.localdomain>
	<4C56C57C.4000800@voidspace.org.uk> <4C571E42.9040408@egenix.com>
	<4C57247F.5060105@voidspace.org.uk> <4C572C93.4040207@egenix.com>
	<20100802213104.E6EFC3A479B@sparrow.telecommunity.com>
	<4C57D317.8080707@egenix.com> <20100803134839.28f39389@pitrou.net>
	<AANLkTinPG=HBL00BLxLb+bPjKumZTpL2xRjrjKf2qeea@mail.gmail.com>
	<4C582932.1010309@voidspace.org.uk>
Message-ID: <AANLkTikW627DhrJhVtBMz3An=GY+Zp_B7BZodvmAr+Sr@mail.gmail.com>

On Tue, Aug 3, 2010 at 11:35 PM, Michael Foord
<fuzzyman at voidspace.org.uk> wrote:
> On 03/08/2010 15:19, David Cournapeau wrote:
>>
>> On Tue, Aug 3, 2010 at 8:48 PM, Antoine Pitrou<solipsis at pitrou.net>
>> ?wrote:
>>
>>>
>>> On Tue, 03 Aug 2010 10:28:07 +0200
>>> "M.-A. Lemburg"<mal at egenix.com> ?wrote:
>>>
>>>>>
>>>>> Don't forget system packaging tools like .deb, .rpm, etc., which do not
>>>>> generally take kindly to updating such things. ?For better or worse,
>>>>> the
>>>>> filesystem *is* our "central database" these days.
>>>>>
>>>>
>>>> I don't think that's a problem: the SQLite database would be a cache
>>>> like e.g. a font cache or TCSH command cache, not a replacement of
>>>> the meta files stored in directories.
>>>>
>>>> Such a database would solve many things at once: faster access to
>>>> the meta-data of installed packages, fewer I/O calls during startup,
>>>> more flexible ways of doing queries on the meta-data, needed for
>>>> introspection and discovery, etc.
>>>>
>>>
>>> If the cache can become stale because of system package management
>>> tools, how do you avoid I/O calls while checking that the database is
>>> fresh enough at startup?
>>>
>>
>> There is a tension between the two approaches: either you want
>> "auto-discovery", or you want a system with explicit registration and
>> only the registered plugins would be visible to the system.
>>
>>
>
> Not true. Auto-discovery provides an API for applications to tell users
> which plugins are *available* whilst still allowing the app to decide which
> are active / enabled. It still leaves full control in the hands of the
> application.

Maybe  I was not clear, but I don't understand how your statement
contradict mine. The issue is how to determine which plugins are
available: if you don't have an explicit registration, you need to
constantly restat every potential location (short of using OS specific
systems to to get notification from fs changes). The current python
solutions that I am familiar with are prohibitively computing
intensive for this reason (think about what happens when you stat
locations on NFS shares).

David

From fuzzyman at voidspace.org.uk  Tue Aug  3 17:43:48 2010
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Tue, 03 Aug 2010 16:43:48 +0100
Subject: [Python-Dev] PEP 376 proposed changes for basic plugins support
In-Reply-To: <AANLkTikW627DhrJhVtBMz3An=GY+Zp_B7BZodvmAr+Sr@mail.gmail.com>
References: <AANLkTinyjMkF2n91zS+48n6B_gkp9szW_bH0XJgTDh7D@mail.gmail.com>	<4C55FF0F.3010702@voidspace.org.uk>	<AANLkTim1af-zWEYF4U-vTr6d+8HkqFCycMVmQYsqpDcN@mail.gmail.com>	<4C5609A3.3090008@voidspace.org.uk>	<AANLkTimU-OUh8fzFoRvHMsQOqVa+jsFTfPyZKeY=heVg@mail.gmail.com>	<20100802010616.5FD133A4758@sparrow.telecommunity.com>	<AANLkTi=UDktBHXeQTU6_ouPk2sfnmhztMLY9yjzZJHP7@mail.gmail.com>	<4C56B846.9090009@egenix.com>	<20100802123145.2305.1286368223.divmod.xquotient.3@localhost.localdomain>	<4C56C57C.4000800@voidspace.org.uk>	<4C571E42.9040408@egenix.com>	<4C57247F.5060105@voidspace.org.uk>	<4C572C93.4040207@egenix.com>	<20100802213104.E6EFC3A479B@sparrow.telecommunity.com>	<4C57D317.8080707@egenix.com>	<20100803134839.28f39389@pitrou.net>	<AANLkTinPG=HBL00BLxLb+bPjKumZTpL2xRjrjKf2qeea@mail.gmail.com>	<4C582932.1010309@voidspace.org.uk>
	<AANLkTikW627DhrJhVtBMz3An=GY+Zp_B7BZodvmAr+Sr@mail.gmail.com>
Message-ID: <4C583934.6090702@voidspace.org.uk>

On 03/08/2010 16:24, David Cournapeau wrote:
> On Tue, Aug 3, 2010 at 11:35 PM, Michael Foord
> <fuzzyman at voidspace.org.uk>  wrote:
>    
>> On 03/08/2010 15:19, David Cournapeau wrote:
>>      
>>> On Tue, Aug 3, 2010 at 8:48 PM, Antoine Pitrou<solipsis at pitrou.net>
>>>   wrote:
>>>
>>>        
>>>> On Tue, 03 Aug 2010 10:28:07 +0200
>>>> "M.-A. Lemburg"<mal at egenix.com>    wrote:
>>>>
>>>>          
>>>>>> Don't forget system packaging tools like .deb, .rpm, etc., which do not
>>>>>> generally take kindly to updating such things.  For better or worse,
>>>>>> the
>>>>>> filesystem *is* our "central database" these days.
>>>>>>
>>>>>>              
>>>>> I don't think that's a problem: the SQLite database would be a cache
>>>>> like e.g. a font cache or TCSH command cache, not a replacement of
>>>>> the meta files stored in directories.
>>>>>
>>>>> Such a database would solve many things at once: faster access to
>>>>> the meta-data of installed packages, fewer I/O calls during startup,
>>>>> more flexible ways of doing queries on the meta-data, needed for
>>>>> introspection and discovery, etc.
>>>>>
>>>>>            
>>>> If the cache can become stale because of system package management
>>>> tools, how do you avoid I/O calls while checking that the database is
>>>> fresh enough at startup?
>>>>
>>>>          
>>> There is a tension between the two approaches: either you want
>>> "auto-discovery", or you want a system with explicit registration and
>>> only the registered plugins would be visible to the system.
>>>
>>>
>>>        
>> Not true. Auto-discovery provides an API for applications to tell users
>> which plugins are *available* whilst still allowing the app to decide which
>> are active / enabled. It still leaves full control in the hands of the
>> application.
>>      
> Maybe  I was not clear, but I don't understand how your statement
> contradict mine. The issue is how to determine which plugins are
> available: if you don't have an explicit registration, you need to
> constantly restat every potential location (short of using OS specific
> systems to to get notification from fs changes). The current python
> solutions that I am familiar with are prohibitively computing
> intensive for this reason (think about what happens when you stat
> locations on NFS shares).
>    

Ah, I thought you were arguing against the plugins proposal altogether. 
If you are merely saying that you prefer the proposal to maintain the 
list of plugins via an explicit registration process (i.e. a central 
file somewhere) rather than "stating around" then I don't *particularly* 
have an opinion on the matter.

I want to use the API and the implementation details are up to others to 
work out. :-)

Sorry for the confusion.

Michael

> David
>    


-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (?BOGUS AGREEMENTS?) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.



From alexander.belopolsky at gmail.com  Tue Aug  3 18:21:47 2010
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Tue, 3 Aug 2010 12:21:47 -0400
Subject: [Python-Dev] co_firstlineno on decorated functions
In-Reply-To: <AANLkTim_sOsL74krpF_Ze0gWcBM7jYUEpaL2_Ng2HK1N@mail.gmail.com>
References: <AANLkTinTg6TuJesKKKVCj-5RcLbit75JTtjrF794qUs-@mail.gmail.com>
	<AANLkTi=7_nNcQ0bcWmtiy8E0-P8Z6doHT-A_wPSdiOum@mail.gmail.com>
	<AANLkTi=5xjs1GioFkw4iGATpZktiuZfh5dZN1fmgwHr8@mail.gmail.com>
	<20100803144832.620b11ae@pitrou.net>
	<AANLkTim_sOsL74krpF_Ze0gWcBM7jYUEpaL2_Ng2HK1N@mail.gmail.com>
Message-ID: <AANLkTin=ZPe3T0K5SXy-dBqn2-rcx-PA3n-202Kky1x+@mail.gmail.com>

On Tue, Aug 3, 2010 at 9:05 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> .. While I'd agree with you for a
> clean slate definition, that's not what we're dealing with here:
> "co_firstlineno" has an existing meaning, and it *isn't* "the line
> containing the def keyword", it's "the first line of the function,
> including any decorator lines". The decision could (and arguably
> should) have gone the other way when decorator syntax was first added,
> but changing our minds now would be making the situation worse rather
> than better.

I agree with Nick.  What I see here is an ambiguity with good
arguments available either way.  Since the decision has been made, it
is better to just stick to it and educate users through better
documentation.

Here is a copy of my private response to Eli a few days ago:
"""
I am not sure there is a bug there.
What is wrong with the following trace?

   1: def d(x):
   1:     return x

   1: @d
      def f():
   1:     x = 0
   6:     for i in range(5):
   5:         x += 2

   1: f()

Arguably, the "def" line should show up in coverage, but it is
not that dissimilar from

   1: def \
      f():
   1:     x = 0
   6:     for i in range(5):
   5:         x += 2

   1: f()

If you think of decorator syntax as a part of the "def" line, the first
trace makes as much sense as the second.
"""

From glyph at twistedmatrix.com  Tue Aug  3 18:33:05 2010
From: glyph at twistedmatrix.com (Glyph Lefkowitz)
Date: Tue, 3 Aug 2010 12:33:05 -0400
Subject: [Python-Dev] PEP 376 proposed changes for basic plugins support
In-Reply-To: <4C57D317.8080707@egenix.com>
References: <AANLkTinyjMkF2n91zS+48n6B_gkp9szW_bH0XJgTDh7D@mail.gmail.com>	<4C55FF0F.3010702@voidspace.org.uk>	<AANLkTim1af-zWEYF4U-vTr6d+8HkqFCycMVmQYsqpDcN@mail.gmail.com>	<4C5609A3.3090008@voidspace.org.uk>	<AANLkTimU-OUh8fzFoRvHMsQOqVa+jsFTfPyZKeY=heVg@mail.gmail.com>	<20100802010616.5FD133A4758@sparrow.telecommunity.com>	<AANLkTi=UDktBHXeQTU6_ouPk2sfnmhztMLY9yjzZJHP7@mail.gmail.com>	<4C56B846.9090009@egenix.com>	<20100802123145.2305.1286368223.divmod.xquotient.3@localhost.localdomain>	<4C56C57C.4000800@voidspace.org.uk>
	<4C571E42.9040408@egenix.com>	<4C57247F.5060105@voidspace.org.uk>
	<4C572C93.4040207@egenix.com>
	<20100802213104.E6EFC3A479B@sparrow.telecommunity.com>
	<4C57D317.8080707@egenix.com>
Message-ID: <FCAE417F-6827-438F-A5C7-3906A9E85CCA@twistedmatrix.com>


On Aug 3, 2010, at 4:28 AM, M.-A. Lemburg wrote:

> I don't think that's a problem: the SQLite database would be a cache
> like e.g. a font cache or TCSH command cache, not a replacement of
> the meta files stored in directories.
> 
> Such a database would solve many things at once: faster access to
> the meta-data of installed packages, fewer I/O calls during startup,
> more flexible ways of doing queries on the meta-data, needed for
> introspection and discovery, etc.

This is exactly what Twisted already does with its plugin cache, and the previously-cited ticket in this thread should expand the types of metadata which can be obtained about plugins.

Packaging systems are perfectly capable of generating and updating such metadata caches, but various packages of Twisted (Debian's especially) didn't read our documentation and kept moving around the place where Python source files were installed, which routinely broke the post-installation hooks and caused all kinds of problems.

I would strongly recommend looping in the Python packaging teams from various distros *before* adding another such cache, unless you want to be fielding bugs from Launchpad.net for five years :).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100803/24ecde33/attachment.html>

From rdmurray at bitdance.com  Tue Aug  3 18:58:31 2010
From: rdmurray at bitdance.com (R. David Murray)
Date: Tue, 03 Aug 2010 12:58:31 -0400
Subject: [Python-Dev] Tracker status
In-Reply-To: <20100803163501.0e53e1f2@pitrou.net>
References: <AANLkTi=fcQJP6SuNSz35+HpCzeDVY8bYEs2VtLS2Mq2z@mail.gmail.com>
	<AANLkTi=a5KhS-X_Ec=2pUbzH71MSNgfrkeYT=qUEehto@mail.gmail.com>
	<AANLkTimO9mYR_u3ghrZNGmPP6puqiP-g7OW9g92c4rjV@mail.gmail.com>
	<AANLkTinPcYfFsHrnKsYZwV18ywESMydDSzKrYv=WF2fG@mail.gmail.com>
	<AANLkTikoT-WLpsrmwKSRGZ7C1fx-uKsnGKGEkOfFE7w+@mail.gmail.com>
	<AANLkTinGB+1VNRGi3suxuMxS_n+cALiUBvGO_LxJsgR2@mail.gmail.com>
	<20100803163501.0e53e1f2@pitrou.net>
Message-ID: <20100803165831.275D2218029@kimball.webabinitio.net>

On Tue, 03 Aug 2010 16:35:01 +0200, Antoine Pitrou <solipsis at pitrou.net> wrote:
> Apparently you are not the only one experiencing it.
> On #python-dev we get such notifications:
> 
> <CIA-31> alanwilter roundup * #9485/signal.signal/signal.alarm not
> working as expected: [new] I have this example code to illustrate a
> problem I am ...
> <CIA-31> alanwilter roundup * #9486/signal.signal/signal.alarm not
> working as expected: [new] I have this example code to illustrate a
> problem I am ... <fdrake> gutworth: Too late.  tarek is lost to us.
> <CIA-31> alanwilter roundup * #9487/signal.signal/signal.alarm not
> working as expected: [new] I have this example code to illustrate a
> problem I am ...
> <CIA-31> alanwilter roundup * #9488/signal.signal/signal.alarm not
> working as expected: [new] I have this example code to illustrate a
> problem I am ...
> 
> But the relevant bug entries don't exist.

Fixed.  Apparently a line was dropped when applying a patch to
the tracker, but the mistake didn't surface until roundup
was restarted after the reboot.

--
R. David Murray                                      www.bitdance.com

From brian.curtin at gmail.com  Tue Aug  3 19:05:57 2010
From: brian.curtin at gmail.com (Brian Curtin)
Date: Tue, 3 Aug 2010 12:05:57 -0500
Subject: [Python-Dev] Tracker status
In-Reply-To: <20100803165831.275D2218029@kimball.webabinitio.net>
References: <AANLkTi=fcQJP6SuNSz35+HpCzeDVY8bYEs2VtLS2Mq2z@mail.gmail.com>
	<AANLkTi=a5KhS-X_Ec=2pUbzH71MSNgfrkeYT=qUEehto@mail.gmail.com>
	<AANLkTimO9mYR_u3ghrZNGmPP6puqiP-g7OW9g92c4rjV@mail.gmail.com>
	<AANLkTinPcYfFsHrnKsYZwV18ywESMydDSzKrYv=WF2fG@mail.gmail.com>
	<AANLkTikoT-WLpsrmwKSRGZ7C1fx-uKsnGKGEkOfFE7w+@mail.gmail.com>
	<AANLkTinGB+1VNRGi3suxuMxS_n+cALiUBvGO_LxJsgR2@mail.gmail.com>
	<20100803163501.0e53e1f2@pitrou.net>
	<20100803165831.275D2218029@kimball.webabinitio.net>
Message-ID: <AANLkTimsSnK+7twhieRHm2fHF=2yHhU7yGX_nesQK2Zt@mail.gmail.com>

On Tue, Aug 3, 2010 at 11:58, R. David Murray <rdmurray at bitdance.com> wrote:

> On Tue, 03 Aug 2010 16:35:01 +0200, Antoine Pitrou <solipsis at pitrou.net>
> wrote:
> > Apparently you are not the only one experiencing it.
> > On #python-dev we get such notifications:
> >
> > <CIA-31> alanwilter roundup * #9485/signal.signal/signal.alarm not
> > working as expected: [new] I have this example code to illustrate a
> > problem I am ...
> > <CIA-31> alanwilter roundup * #9486/signal.signal/signal.alarm not
> > working as expected: [new] I have this example code to illustrate a
> > problem I am ... <fdrake> gutworth: Too late.  tarek is lost to us.
> > <CIA-31> alanwilter roundup * #9487/signal.signal/signal.alarm not
> > working as expected: [new] I have this example code to illustrate a
> > problem I am ...
> > <CIA-31> alanwilter roundup * #9488/signal.signal/signal.alarm not
> > working as expected: [new] I have this example code to illustrate a
> > problem I am ...
> >
> > But the relevant bug entries don't exist.
>
> Fixed.  Apparently a line was dropped when applying a patch to
> the tracker, but the mistake didn't surface until roundup
> was restarted after the reboot.
>
> --
> R. David Murray                                      www.bitdance.com


Are these issues going to show up or are they lost? Via IRC, #9490 and it's
apparent dupe #9491 looked interesting to me (Windows service related).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100803/e1598062/attachment.html>

From steve at holdenweb.com  Tue Aug  3 19:05:58 2010
From: steve at holdenweb.com (Steve Holden)
Date: Tue, 03 Aug 2010 13:05:58 -0400
Subject: [Python-Dev] PEP 376 proposed changes for basic plugins support
In-Reply-To: <FCAE417F-6827-438F-A5C7-3906A9E85CCA@twistedmatrix.com>
References: <AANLkTinyjMkF2n91zS+48n6B_gkp9szW_bH0XJgTDh7D@mail.gmail.com>	<4C55FF0F.3010702@voidspace.org.uk>	<AANLkTim1af-zWEYF4U-vTr6d+8HkqFCycMVmQYsqpDcN@mail.gmail.com>	<4C5609A3.3090008@voidspace.org.uk>	<AANLkTimU-OUh8fzFoRvHMsQOqVa+jsFTfPyZKeY=heVg@mail.gmail.com>	<20100802010616.5FD133A4758@sparrow.telecommunity.com>	<AANLkTi=UDktBHXeQTU6_ouPk2sfnmhztMLY9yjzZJHP7@mail.gmail.com>	<4C56B846.9090009@egenix.com>	<20100802123145.2305.1286368223.divmod.xquotient.3@localhost.localdomain>	<4C56C57C.4000800@voidspace.org.uk>	<4C571E42.9040408@egenix.com>	<4C57247F.5060105@voidspace.org.uk>	<4C572C93.4040207@egenix.com>	<20100802213104.E6EFC3A479B@sparrow.telecommunity.com>	<4C57D317.8080707@egenix.com>
	<FCAE417F-6827-438F-A5C7-3906A9E85CCA@twistedmatrix.com>
Message-ID: <4C584C76.40000@holdenweb.com>

On 8/3/2010 12:33 PM, Glyph Lefkowitz wrote:
> 
> On Aug 3, 2010, at 4:28 AM, M.-A. Lemburg wrote:
> 
>> I don't think that's a problem: the SQLite database would be a cache
>> like e.g. a font cache or TCSH command cache, not a replacement of
>> the meta files stored in directories.
>>
>> Such a database would solve many things at once: faster access to
>> the meta-data of installed packages, fewer I/O calls during startup,
>> more flexible ways of doing queries on the meta-data, needed for
>> introspection and discovery, etc.
> 
> This is exactly what Twisted already does with its plugin cache, and the
> previously-cited ticket in this thread should expand the types of
> metadata which can be obtained about plugins.
> +1
> Packaging systems are perfectly capable of generating and updating such
> metadata caches, but various packages of Twisted (Debian's especially)
> didn't read our documentation and kept moving around the place where
> Python source files were installed, which routinely broke the
> post-installation hooks and caused all kinds of problems.
> 
> I would strongly recommend looping in the Python packaging teams from
> various distros *before* adding another such cache, unless you want to
> be fielding bugs from Launchpad.net <http://Launchpad.net> for five
> years :).
> 
+1
-- 
Steve Holden           +1 571 484 6266   +1 800 494 3119
DjangoCon US September 7-9, 2010    http://djangocon.us/
See Python Video!       http://python.mirocommunity.org/
Holden Web LLC                 http://www.holdenweb.com/

From steve at holdenweb.com  Tue Aug  3 19:05:58 2010
From: steve at holdenweb.com (Steve Holden)
Date: Tue, 03 Aug 2010 13:05:58 -0400
Subject: [Python-Dev] PEP 376 proposed changes for basic plugins support
In-Reply-To: <FCAE417F-6827-438F-A5C7-3906A9E85CCA@twistedmatrix.com>
References: <AANLkTinyjMkF2n91zS+48n6B_gkp9szW_bH0XJgTDh7D@mail.gmail.com>	<4C55FF0F.3010702@voidspace.org.uk>	<AANLkTim1af-zWEYF4U-vTr6d+8HkqFCycMVmQYsqpDcN@mail.gmail.com>	<4C5609A3.3090008@voidspace.org.uk>	<AANLkTimU-OUh8fzFoRvHMsQOqVa+jsFTfPyZKeY=heVg@mail.gmail.com>	<20100802010616.5FD133A4758@sparrow.telecommunity.com>	<AANLkTi=UDktBHXeQTU6_ouPk2sfnmhztMLY9yjzZJHP7@mail.gmail.com>	<4C56B846.9090009@egenix.com>	<20100802123145.2305.1286368223.divmod.xquotient.3@localhost.localdomain>	<4C56C57C.4000800@voidspace.org.uk>	<4C571E42.9040408@egenix.com>	<4C57247F.5060105@voidspace.org.uk>	<4C572C93.4040207@egenix.com>	<20100802213104.E6EFC3A479B@sparrow.telecommunity.com>	<4C57D317.8080707@egenix.com>
	<FCAE417F-6827-438F-A5C7-3906A9E85CCA@twistedmatrix.com>
Message-ID: <4C584C76.40000@holdenweb.com>

On 8/3/2010 12:33 PM, Glyph Lefkowitz wrote:
> 
> On Aug 3, 2010, at 4:28 AM, M.-A. Lemburg wrote:
> 
>> I don't think that's a problem: the SQLite database would be a cache
>> like e.g. a font cache or TCSH command cache, not a replacement of
>> the meta files stored in directories.
>>
>> Such a database would solve many things at once: faster access to
>> the meta-data of installed packages, fewer I/O calls during startup,
>> more flexible ways of doing queries on the meta-data, needed for
>> introspection and discovery, etc.
> 
> This is exactly what Twisted already does with its plugin cache, and the
> previously-cited ticket in this thread should expand the types of
> metadata which can be obtained about plugins.
> +1
> Packaging systems are perfectly capable of generating and updating such
> metadata caches, but various packages of Twisted (Debian's especially)
> didn't read our documentation and kept moving around the place where
> Python source files were installed, which routinely broke the
> post-installation hooks and caused all kinds of problems.
> 
> I would strongly recommend looping in the Python packaging teams from
> various distros *before* adding another such cache, unless you want to
> be fielding bugs from Launchpad.net <http://Launchpad.net> for five
> years :).
> 
+1
-- 
Steve Holden           +1 571 484 6266   +1 800 494 3119
DjangoCon US September 7-9, 2010    http://djangocon.us/
See Python Video!       http://python.mirocommunity.org/
Holden Web LLC                 http://www.holdenweb.com/


From rdmurray at bitdance.com  Tue Aug  3 19:07:38 2010
From: rdmurray at bitdance.com (R. David Murray)
Date: Tue, 03 Aug 2010 13:07:38 -0400
Subject: [Python-Dev] breaking an exception chain
Message-ID: <20100803170738.3F24321806F@kimball.webabinitio.net>

Working with Catherine on an argparse bug, we ran into a test that was
apparently failing by raising a SystemExit, when the test harness was
supposed to be catching that error.  It took us a bit to realize that
there wasn't really a SystemExit error, but that what we were seeing was
the SystemExit chained to the exception the test harness was purposfully
raising after catching the SystemExit.  In Python2, only the second,
intentionally raised exception would be printed by unittest.  In Python3,
the "main error" printed by unittest is the SystemExit, and the error
raised by the test harness appears after the "while processing the above
error" sentence.  Needless to say, this is a bit confusing.

So I thought I'd break the exception chain before raising the error the
test harness really wants to raise.  However, I can't figure out any way
to do that.  Am I missing something, or this a missing feature?

--
R. David Murray                                      www.bitdance.com

From benjamin at python.org  Tue Aug  3 19:22:30 2010
From: benjamin at python.org (Benjamin Peterson)
Date: Tue, 3 Aug 2010 12:22:30 -0500
Subject: [Python-Dev] breaking an exception chain
In-Reply-To: <20100803170738.3F24321806F@kimball.webabinitio.net>
References: <20100803170738.3F24321806F@kimball.webabinitio.net>
Message-ID: <AANLkTikJtYA-bTCimd2Kj+jWPzV2DfbpaHBq7=_2KJJR@mail.gmail.com>

2010/8/3 R. David Murray <rdmurray at bitdance.com>:
> Working with Catherine on an argparse bug, we ran into a test that was
> apparently failing by raising a SystemExit, when the test harness was
> supposed to be catching that error. ?It took us a bit to realize that
> there wasn't really a SystemExit error, but that what we were seeing was
> the SystemExit chained to the exception the test harness was purposfully
> raising after catching the SystemExit. ?In Python2, only the second,
> intentionally raised exception would be printed by unittest. ?In Python3,
> the "main error" printed by unittest is the SystemExit, and the error
> raised by the test harness appears after the "while processing the above
> error" sentence. ?Needless to say, this is a bit confusing.
>
> So I thought I'd break the exception chain before raising the error the
> test harness really wants to raise. ?However, I can't figure out any way
> to do that. ?Am I missing something, or this a missing feature?

Missing feature; there's a bug report somewhere.



-- 
Regards,
Benjamin

From tjreedy at udel.edu  Tue Aug  3 19:25:28 2010
From: tjreedy at udel.edu (Terry Reedy)
Date: Tue, 03 Aug 2010 13:25:28 -0400
Subject: [Python-Dev] co_firstlineno on decorated functions
In-Reply-To: <20100803144832.620b11ae@pitrou.net>
References: <AANLkTinTg6TuJesKKKVCj-5RcLbit75JTtjrF794qUs-@mail.gmail.com>	<AANLkTi=7_nNcQ0bcWmtiy8E0-P8Z6doHT-A_wPSdiOum@mail.gmail.com>	<AANLkTi=5xjs1GioFkw4iGATpZktiuZfh5dZN1fmgwHr8@mail.gmail.com>
	<20100803144832.620b11ae@pitrou.net>
Message-ID: <i39je5$6jh$1@dough.gmane.org>

On 8/3/2010 8:48 AM, Antoine Pitrou wrote:
> On Tue, 3 Aug 2010 22:25:01 +1000
> Nick Coghlan<ncoghlan at gmail.com>  wrote:
>> On Tue, Aug 3, 2010 at 1:40 PM, Eli Bendersky<eliben at gmail.com>  wrote:
>>> The first print out correctly specifies the line "def foo" is in. However,
>>> the second one points to the line with "@dummydecorator" instead of "def
>>> bar". [Python 2.6]
>>>
>>> The side-effects of this behavior can be easily seen in the output of
>>> modules like trace and profile. Would you say it's normal, or could this be
>>> considered a bug?
>>
>> Since the decorator is as much a part of the function definition as
>> the def line is, I would say that it is correct (the name says
>> "firstlineno", not "deflineno").
>
> That's debatable. Since writing:
>
> @b
> def a():
>      ...
>
> is equivalent to:
>
> def a():
>      ...
> a = b(a)

The difference is that 'a=b(a)' is a standalone statement which could 
moved down with other statements interposed, while '@b' is neither a 
statement nor expression but a def statement prefix, and is documented 
as such.

A dynamic difference between the constructs, as least with CPython, is 
that the decorator form does just one namespace binding instead of two.

> and in the latter case co_firstlineno points to the "def a()" line.
>
> Furthermore, co_firstlineno is an attribute of the code object, not the
> function object, so it shouldn't ideally depend on whether a decorator
> was applied or not.

Perhaps. A practical consideration is that it is easier to search 
forward from the first '@' line to the 'def' line than the reverse.

-- 
Terry Jan Reedy


From g.brandl at gmx.net  Tue Aug  3 20:36:36 2010
From: g.brandl at gmx.net (Georg Brandl)
Date: Tue, 03 Aug 2010 20:36:36 +0200
Subject: [Python-Dev] Tracker status
In-Reply-To: <AANLkTimsSnK+7twhieRHm2fHF=2yHhU7yGX_nesQK2Zt@mail.gmail.com>
References: <AANLkTi=fcQJP6SuNSz35+HpCzeDVY8bYEs2VtLS2Mq2z@mail.gmail.com>	<AANLkTi=a5KhS-X_Ec=2pUbzH71MSNgfrkeYT=qUEehto@mail.gmail.com>	<AANLkTimO9mYR_u3ghrZNGmPP6puqiP-g7OW9g92c4rjV@mail.gmail.com>	<AANLkTinPcYfFsHrnKsYZwV18ywESMydDSzKrYv=WF2fG@mail.gmail.com>	<AANLkTikoT-WLpsrmwKSRGZ7C1fx-uKsnGKGEkOfFE7w+@mail.gmail.com>	<AANLkTinGB+1VNRGi3suxuMxS_n+cALiUBvGO_LxJsgR2@mail.gmail.com>	<20100803163501.0e53e1f2@pitrou.net>	<20100803165831.275D2218029@kimball.webabinitio.net>
	<AANLkTimsSnK+7twhieRHm2fHF=2yHhU7yGX_nesQK2Zt@mail.gmail.com>
Message-ID: <i39no8$mbg$1@dough.gmane.org>

Am 03.08.2010 19:05, schrieb Brian Curtin:
> On Tue, Aug 3, 2010 at 11:58, R. David Murray <rdmurray at bitdance.com

>     Fixed.  Apparently a line was dropped when applying a patch to
>     the tracker, but the mistake didn't surface until roundup
>     was restarted after the reboot.
> 
>     --
>     R. David Murray                                      www.bitdance.com
>     <http://www.bitdance.com>
> 
> 
> Are these issues going to show up or are they lost? Via IRC, #9490 and it's
> apparent dupe #9491 looked interesting to me (Windows service related).
> 

I would recommend contacting the poster via the address he registered
in the tracker.

Georg


From barry at python.org  Tue Aug  3 21:30:40 2010
From: barry at python.org (Barry Warsaw)
Date: Tue, 3 Aug 2010 15:30:40 -0400
Subject: [Python-Dev] release26-maint semi-frozen
Message-ID: <20100803153040.01dda7ad@heresy>

We're going to go ahead and cut the 2.6.6rc1 release tonight, bugs.python.org
willing.  We've got a fairly clean test run on local hardware across OS X,
Linux (Debian, Ubuntu), and Brian is looking at Windows now (the buildbots are
a sad and sorry story).  Ezio has done a great amount of work on getting 2.6.6
pretty clean with -3 warnings too.

Please consider the release26-maint tree closed for commits (except svnmerges)
for the next 2.5 hours.  I'll send another message at about 2200 UTC when I
freeze the tree for those commits too.  You can request exceptions by pinging
me on #python-dev or (if you're feeling lucky ;) sending me an email.

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100803/ba3ccc8f/attachment.pgp>

From kristjan at ccpgames.com  Tue Aug  3 21:38:47 2010
From: kristjan at ccpgames.com (=?iso-8859-1?Q?Kristj=E1n_Valur_J=F3nsson?=)
Date: Tue, 3 Aug 2010 19:38:47 +0000
Subject: [Python-Dev] pickle output not unique
Message-ID: <930F189C8A437347B80DF2C156F7EC7F0B8D41B488@exchis.ccp.ad.local>

Hi there.
I was made aware of this oddity here:
import cPickle

reffed = "xKITTENSx"[1:-1]
print repr(cPickle.dumps(reffed))

print repr(cPickle.dumps("xKITTENSx"[1:-1]))

These strings are different, presumably because of the (ob_refcnt == 1) optimization used during object pickling.
This might come as a suprise to many, and is potentially dangerous if pickling is being used as precursor to some hashing function.
For example, we use code that caches function calls, using something akin to:

myhash = hash(cPickle.dumps(arguments))
try:
  cached_args, cached_value = cache[myhash]
  if cached_args == arguments: return cached_value
except KeyError:
  value = Function(*args)
  cache[myhash] = artuments, value
  return value

The non-uniqueness of the pickle string will cause unnecessary cache misses in this code.  Pickling is useful as a precusor because it allows for more varied object types than hash() alone would.

I just wanted to point this out.  We'll attempt some local workarounds here, but it should otherwise be simple to modify pickling to optionally turn off this optimization and always generate the same output irrespective of the internal reference counts of the objects.

Cheers,

Kristj?n

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100803/bb8a84d7/attachment.html>

From rdmurray at bitdance.com  Tue Aug  3 21:53:16 2010
From: rdmurray at bitdance.com (R. David Murray)
Date: Tue, 03 Aug 2010 15:53:16 -0400
Subject: [Python-Dev] breaking an exception chain
In-Reply-To: <AANLkTikJtYA-bTCimd2Kj+jWPzV2DfbpaHBq7=_2KJJR@mail.gmail.com>
References: <20100803170738.3F24321806F@kimball.webabinitio.net>
	<AANLkTikJtYA-bTCimd2Kj+jWPzV2DfbpaHBq7=_2KJJR@mail.gmail.com>
Message-ID: <20100803195316.83B221FE557@kimball.webabinitio.net>

On Tue, 03 Aug 2010 12:22:30 -0500, Benjamin Peterson <benjamin at python.org> wrote:
> 2010/8/3 R. David Murray <rdmurray at bitdance.com>:
> > So I thought I'd break the exception chain before raising the error the
> > test harness really wants to raise.  However, I can't figure out any way
> > to do that.  Am I missing something, or this a missing feature?
> 
> Missing feature; there's a bug report somewhere.

Ah, thank you.  Issue 6210.  It has a workaround, too.

--
R. David Murray                                      www.bitdance.com

From rdmurray at bitdance.com  Tue Aug  3 21:56:42 2010
From: rdmurray at bitdance.com (R. David Murray)
Date: Tue, 03 Aug 2010 15:56:42 -0400
Subject: [Python-Dev] Tracker status
In-Reply-To: <i39no8$mbg$1@dough.gmane.org>
References: <AANLkTi=fcQJP6SuNSz35+HpCzeDVY8bYEs2VtLS2Mq2z@mail.gmail.com>
	<AANLkTi=a5KhS-X_Ec=2pUbzH71MSNgfrkeYT=qUEehto@mail.gmail.com>
	<AANLkTimO9mYR_u3ghrZNGmPP6puqiP-g7OW9g92c4rjV@mail.gmail.com>
	<AANLkTinPcYfFsHrnKsYZwV18ywESMydDSzKrYv=WF2fG@mail.gmail.com>
	<AANLkTikoT-WLpsrmwKSRGZ7C1fx-uKsnGKGEkOfFE7w+@mail.gmail.com>
	<AANLkTinGB+1VNRGi3suxuMxS_n+cALiUBvGO_LxJsgR2@mail.gmail.com>
	<20100803163501.0e53e1f2@pitrou.net>
	<20100803165831.275D2218029@kimball.webabinitio.net>
	<AANLkTimsSnK+7twhieRHm2fHF=2yHhU7yGX_nesQK2Zt@mail.gmail.com>
	<i39no8$mbg$1@dough.gmane.org>
Message-ID: <20100803195642.A20DE1FD2EA@kimball.webabinitio.net>

On Tue, 03 Aug 2010 20:36:36 +0200, Georg Brandl <g.brandl at gmx.net> wrote:
> Am 03.08.2010 19:05, schrieb Brian Curtin:
> > On Tue, Aug 3, 2010 at 11:58, R. David Murray <rdmurray at bitdance.com
> 
> >     Fixed.  Apparently a line was dropped when applying a patch to
> >     the tracker, but the mistake didn't surface until roundup
> >     was restarted after the reboot.
> > 
> > Are these issues going to show up or are they lost? Via IRC, #9490 and it's
> > apparent dupe #9491 looked interesting to me (Windows service related).
> 
> I would recommend contacting the poster via the address he registered
> in the tracker.

Yes, please do that.  As far as I know the issues never got created,
even though the issue counter did increment.

--David

From martin at v.loewis.de  Tue Aug  3 22:48:23 2010
From: martin at v.loewis.de (=?windows-1252?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 03 Aug 2010 22:48:23 +0200
Subject: [Python-Dev] pickle output not unique
In-Reply-To: <930F189C8A437347B80DF2C156F7EC7F0B8D41B488@exchis.ccp.ad.local>
References: <930F189C8A437347B80DF2C156F7EC7F0B8D41B488@exchis.ccp.ad.local>
Message-ID: <4C588097.9090108@v.loewis.de>

> I just wanted to point this out.  We?ll attempt some local workarounds
> here, but it should otherwise be simple to modify pickling to optionally
> turn off this optimization and always generate the same output
> irrespective of the internal reference counts of the objects.

I think there are many other instances where values that compare equal
pickle differently in Python. By relying on this property for hashing,
you are really operating on thin ice.

Regards,
Martin

From alexander.belopolsky at gmail.com  Tue Aug  3 22:51:53 2010
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Tue, 3 Aug 2010 16:51:53 -0400
Subject: [Python-Dev] pickle output not unique
In-Reply-To: <930F189C8A437347B80DF2C156F7EC7F0B8D41B488@exchis.ccp.ad.local>
References: <930F189C8A437347B80DF2C156F7EC7F0B8D41B488@exchis.ccp.ad.local>
Message-ID: <AANLkTin4dmj9ArUp6na8Q7pMwcRTOjSov9D6FovWPmnD@mail.gmail.com>

2010/8/3 Kristj?n Valur J?nsson <kristjan at ccpgames.com>:
..
>
> These strings are different, presumably because of the (ob_refcnt == 1)
> optimization used during object pickling.
>
I have recently closed a similar issue because it is not a bug and the
problem is not present in 3.x: http://bugs.python.org/issue8738

..
> I just wanted to point this out.? We?ll attempt some local workarounds here,
> but it should otherwise be simple to modify pickling to optionally turn off
> this optimization and always generate the same output irrespective of the
> internal reference counts of the objects.

I wonder if it would help if rather than trying to turn off the ad-hoc
optimization, you run your pickle strings through
pickletools.optimize.

From alexander.belopolsky at gmail.com  Wed Aug  4 00:04:32 2010
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Tue, 3 Aug 2010 18:04:32 -0400
Subject: [Python-Dev] pickle output not unique
In-Reply-To: <4C588097.9090108@v.loewis.de>
References: <930F189C8A437347B80DF2C156F7EC7F0B8D41B488@exchis.ccp.ad.local>
	<4C588097.9090108@v.loewis.de>
Message-ID: <AANLkTimGMUoQzgUq++PfMbnmBLxsGo3EmgSi2U5DTbAq@mail.gmail.com>

2010/8/3 "Martin v. L?wis" <martin at v.loewis.de>:
..
> I think there are many other instances where values that compare equal
> pickle differently in Python.

Indeed.  For example:

>>> 1.0 == 1
True
>>> dumps(1.0) == dumps(1)
False

or for objects of the same type

>>> 0.0 == -0.0
True
>>> dumps(0.0) == dumps(-0.0)
False

From greg.ewing at canterbury.ac.nz  Wed Aug  4 01:04:27 2010
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Wed, 04 Aug 2010 11:04:27 +1200
Subject: [Python-Dev] co_firstlineno on decorated functions
In-Reply-To: <AANLkTinnpOOi9tLHvBetR1i6jS-XOUFiUA=QxVW-9DQk@mail.gmail.com>
References: <AANLkTinTg6TuJesKKKVCj-5RcLbit75JTtjrF794qUs-@mail.gmail.com>
	<AANLkTi=7_nNcQ0bcWmtiy8E0-P8Z6doHT-A_wPSdiOum@mail.gmail.com>
	<AANLkTi=5xjs1GioFkw4iGATpZktiuZfh5dZN1fmgwHr8@mail.gmail.com>
	<20100803144832.620b11ae@pitrou.net>
	<AANLkTim_sOsL74krpF_Ze0gWcBM7jYUEpaL2_Ng2HK1N@mail.gmail.com>
	<AANLkTinnpOOi9tLHvBetR1i6jS-XOUFiUA=QxVW-9DQk@mail.gmail.com>
Message-ID: <4C58A07B.2000006@canterbury.ac.nz>

Guido van Rossum wrote:

> What are the use cases for co_firstlineno? Even if it is for
> displaying the source code, I can find virtue for both sides of this
> argument.

Seems to me that if the code is being displayed to a
human, the decorators are an important thing to know
about, so including them is good.

-- 
Greg

From solipsis at pitrou.net  Wed Aug  4 02:43:39 2010
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 4 Aug 2010 02:43:39 +0200
Subject: [Python-Dev] Status of Lib/_threading_local.py ?
Message-ID: <20100804024339.51b45ac7@pitrou.net>


Hello,

While Lib/_threading_local.py is meant as a fallback Python
implementation of thread-local objects, it looks like it will never be
invoked in practice. The reason is that the thread-local code in
Modules/_threadmodule.c in unconditionally compiled. Furthermore,
_threading_local.py imports threading which itself imports _thread, so
it's not possible for _threading_local to function if for some reason
_thread fails to build or import.

What should we do with _threading_local? Keep it as an example of a
Python implementation (which is vastly slower than what a C
implementation can do and also currently less robust), or plainly
remove it?

Regards

Antoine.



From steve at holdenweb.com  Wed Aug  4 03:08:31 2010
From: steve at holdenweb.com (Steve Holden)
Date: Tue, 03 Aug 2010 21:08:31 -0400
Subject: [Python-Dev] Windows
Message-ID: <i3aeij$146$1@dough.gmane.org>

It's a little disappointing to discover that despite the relatively
large number of developers who have received MSDN licenses from
Microsoft, none if us have the time to make sure that the buildbots are
green for the 2.6.6 release.

I wonder if anyone can think of a way we can get some Windows skillz
into the group that could assist at ties like this. Some brainstorming
might find a way through.

regards
 Steve
-- 
Steve Holden           +1 571 484 6266   +1 800 494 3119
DjangoCon US September 7-9, 2010    http://djangocon.us/
See Python Video!       http://python.mirocommunity.org/
Holden Web LLC                 http://www.holdenweb.com/


From brian.curtin at gmail.com  Wed Aug  4 04:10:47 2010
From: brian.curtin at gmail.com (Brian Curtin)
Date: Tue, 3 Aug 2010 21:10:47 -0500
Subject: [Python-Dev] Windows
In-Reply-To: <i3aeij$146$1@dough.gmane.org>
References: <i3aeij$146$1@dough.gmane.org>
Message-ID: <AANLkTinM+aXsT0gvOP-PkL=hHuRNCJA7z2kvUqOsqe20@mail.gmail.com>

On Tue, Aug 3, 2010 at 20:08, Steve Holden <steve at holdenweb.com> wrote:

> It's a little disappointing to discover that despite the relatively
> large number of developers who have received MSDN licenses from
> Microsoft, none if us have the time to make sure that the buildbots are
> green for the 2.6.6 release.
>
> I wonder if anyone can think of a way we can get some Windows skillz
> into the group that could assist at ties like this. Some brainstorming
> might find a way through.
>
> regards
>  Steve


In my case, 2.6 in general just fell off the radar. 2/3 of the 2.6 Windows
buildbots are fine, with the failing one being the case of a very slow VM
machine and a time sensitive bsddb test. I looked into it this afternoon and
it's something we can improve test-wise -- I'll see if I can work up a
patch. It's not a problem with the module itself.

As for getting the attention of more Windows devs, there are a few names I
see pop up from time to time that would be nice to have on board if they
have the time. I'll see if I can reach out and gauge their interest level.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100803/4071e04d/attachment.html>

From skippy.hammond at gmail.com  Wed Aug  4 06:34:38 2010
From: skippy.hammond at gmail.com (Mark Hammond)
Date: Wed, 04 Aug 2010 14:34:38 +1000
Subject: [Python-Dev] Windows
In-Reply-To: <i3aeij$146$1@dough.gmane.org>
References: <i3aeij$146$1@dough.gmane.org>
Message-ID: <4C58EDDE.6050009@gmail.com>

On 4/08/2010 11:08 AM, Steve Holden wrote:
> It's a little disappointing to discover that despite the relatively
> large number of developers who have received MSDN licenses from
> Microsoft, none if us have the time to make sure that the buildbots are
> green for the 2.6.6 release.
>
> I wonder if anyone can think of a way we can get some Windows skillz
> into the group that could assist at ties like this. Some brainstorming
> might find a way through.

I never go looking at the buildbots to look for problems - maybe some 
way of explicitly bringing such failures to peoples attention would be 
good - I don't recall seeing anything recently on python-dev which would 
prompt me to take a look.

Visiting http://www.python.org/dev/buildbot/2.6/ shows a single Windows 
buildbot that seems to have been green for the last few builds - am I 
looking in the wrong place?

Mark

From kippesp at gmail.com  Wed Aug  4 07:00:27 2010
From: kippesp at gmail.com (Paul Kippes)
Date: Wed, 4 Aug 2010 00:00:27 -0500
Subject: [Python-Dev] Windows MSI installer with minimal options
Message-ID: <AANLkTikG3xn3d-3pc_Ec54x_Gg_yF6_fcP+=YYb1yKid@mail.gmail.com>

Martin,

For the most part, the information at
http://www.python.org/download/releases/2.4/msi/ assisted me with
automating a 2.7 installation on Windows XP.  The following initial
attempt, however, failed to provide a working python installation.
(Messages are either "The system cannot execute the specified
program." or "This application has failed to start because the
application configuration is incorrect.  Reinstalling the application
may fix this problem.")

msiexec /qb /i python-2.7.msi ALLUSERS=1 ADDLOCAL=Extensions

After looking through Tools/msi/msi.py, I was able to automate a
minimal and working Python installation with this adjustment:

ADDLOCAL=Extensions,SharedCRT

Since the only reference I could find to the above web page was when
the MSI installer was first announced
(http://www.python.org/download/releases/2.4.2), the installer options
may have changed since then.

Would you check if my change is what you intended and perhaps migrate
the web page of the 2.4 release note to 2.7?

Thanks!

From sara_hasanlo at yahoo.com  Wed Aug  4 08:39:04 2010
From: sara_hasanlo at yahoo.com (Sarah Hasanlo Nikfar)
Date: Tue, 3 Aug 2010 23:39:04 -0700 (PDT)
Subject: [Python-Dev] (no subject)
Message-ID: <920273.44847.qm@web65817.mail.ac4.yahoo.com>




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100803/fa996848/attachment.html>

From sara_hasanlo at yahoo.com  Wed Aug  4 08:43:15 2010
From: sara_hasanlo at yahoo.com (Sarah Hasanlo Nikfar)
Date: Tue, 3 Aug 2010 23:43:15 -0700 (PDT)
Subject: [Python-Dev] question
Message-ID: <770261.21244.qm@web65811.mail.ac4.yahoo.com>

hi 
i face with problem when i run one sample on cygwin:
please help me
?
Exception happened during processing of request from ('127.0.0.1', 49154)
Traceback (most recent call last):
? File "/usr/local/lib/python2.5/SocketServer.py", line 222, in handle_request
??? self.process_request(request, client_address)
? File "/usr/local/lib/python2.5/SocketServer.py", line 241, in process_request
??? self.finish_request(request, client_address)
? File "/usr/local/lib/python2.5/SocketServer.py", line 254, in finish_request
??? self.RequestHandlerClass(request, client_address, self)
? File "/usr/local/lib/python2.5/SocketServer.py", line 522, in __init__
??? self.handle()
? File "/usr/local/lib/python2.5/BaseHTTPServer.py", line 316, in handle
??? self.handle_one_request()
? File "/usr/local/lib/python2.5/BaseHTTPServer.py", line 310, in handle_one_req
uest
??? method()
? File "/usr/local/lib/python2.5/SimpleHTTPServer.py", line 46, in do_GET
??? self.copyfile(f, self.wfile)
? File "/usr/local/lib/python2.5/SimpleHTTPServer.py", line 175, in copyfile
??? shutil.copyfileobj(source, outputfile)
? File "/usr/local/lib/python2.5/shutil.py", line 29, in copyfileobj
??? fdst.write(buf)
? File "/usr/local/lib/python2.5/socket.py", line 274, in write
??? self.flush()
? File "/usr/local/lib/python2.5/socket.py", line 261, in flush
??? self._sock.sendall(buffer)
error: (113, 'Software caused connection abort')


      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100803/d4b65a54/attachment.html>

From orsenthil at gmail.com  Wed Aug  4 09:08:04 2010
From: orsenthil at gmail.com (Senthil Kumaran)
Date: Wed, 4 Aug 2010 12:38:04 +0530
Subject: [Python-Dev] question
In-Reply-To: <770261.21244.qm@web65811.mail.ac4.yahoo.com>
References: <770261.21244.qm@web65811.mail.ac4.yahoo.com>
Message-ID: <AANLkTinaGEY6OpkKCUW5z+Fuxx2Gsm6sE44QEJ06zyOq@mail.gmail.com>

Hello,

Please ask the support questions at:

http://groups.google.com/group/comp.lang.python

This group is for developing python.


On Wed, Aug 4, 2010 at 12:13 PM, Sarah Hasanlo Nikfar
<sara_hasanlo at yahoo.com> wrote:
> hi
> i face with problem when i run one sample on cygwin:
> please help me
>
> Exception happened during processing of request from ('127.0.0.1', 49154)
> Traceback (most recent call last):
> ? File "/usr/local/lib/python2.5/SocketServer.py", line 222, in
> handle_request
> ??? self.process_request(request, client_address)
> ? File "/usr/local/lib/python2.5/SocketServer.py", line 241, in
> process_request
> ??? self.finish_request(request, client_address)
> ? File "/usr/local/lib/python2.5/SocketServer.py", line 254, in
> finish_request
> ??? self.RequestHandlerClass(request, client_address, self)
> ? File "/usr/local/lib/python2.5/SocketServer.py", line 522, in __init__
> ??? self.handle()
> ? File "/usr/local/lib/python2.5/BaseHTTPServer.py", line 316, in handle
> ??? self.handle_one_request()
> ? File "/usr/local/lib/python2.5/BaseHTTPServer.py", line 310, in
> handle_one_req
> uest
> ??? method()
> ? File "/usr/local/lib/python2.5/SimpleHTTPServer.py", line 46, in do_GET
> ??? self.copyfile(f, self.wfile)
> ? File "/usr/local/lib/python2.5/SimpleHTTPServer.py", line 175, in copyfile
> ??? shutil.copyfileobj(source, outputfile)
> ? File "/usr/local/lib/python2.5/shutil.py", line 29, in copyfileobj
> ??? fdst.write(buf)
> ? File "/usr/local/lib/python2.5/socket.py", line 274, in write
> ??? self.flush()
> ? File "/usr/local/lib/python2.5/socket.py", line 261, in flush
> ??? self._sock.sendall(buffer)
> error: (113, 'Software caused connection abort')
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/orsenthil%40gmail.com
>
>



-- 
Senthil

From mail at timgolden.me.uk  Wed Aug  4 09:49:13 2010
From: mail at timgolden.me.uk (Tim Golden)
Date: Wed, 04 Aug 2010 08:49:13 +0100
Subject: [Python-Dev] Windows
In-Reply-To: <i3aeij$146$1@dough.gmane.org>
References: <i3aeij$146$1@dough.gmane.org>
Message-ID: <4C591B79.9020407@timgolden.me.uk>

On 04/08/2010 02:08, Steve Holden wrote:
> It's a little disappointing to discover that despite the relatively
> large number of developers who have received MSDN licenses from
> Microsoft, none if us have the time to make sure that the buildbots are
> green for the 2.6.6 release.
>
> I wonder if anyone can think of a way we can get some Windows skillz
> into the group that could assist at ties like this. Some brainstorming
> might find a way through.

My own problem is just the amount of ramp-up time (as a proportion of
my own available time) to get hold of a problem even when I see it.
(Speaking here in the more general sense of fixing Windows-related
Python bugs).

As one who has benefitted from the MSDN largesse I am certainly conscious of
the responsibility to contribute benefits back to the Python community.
On the basis that I'm far more likely to watch a buildbot which I actually
administer, I have recently nudged my sysadmins here to see if they can
make good on their promise to find me a spare server to use as a buildbot.

I have watched the buildbot pages occasionally, especially when I see
Windows-related commits going in, but several times "red" buildbots
have turned out to be -- apparently -- environmental / local issues
unrelated to commits. Obviously I could/should have contacted the
buildbot owner to at least inform him or her that something was amiss.
But somehow at that point one's technical enthusiasm for fixing a
problem diminishes when it's not clear that there *is* a problem.
(Grumble, grumble, mutter, mutter... :) )

While we'd certainly benefit from more Windows skills, we'd probably
benefit more from people who have more *time* to look at Windows
issues. OK; to propose something concrete: I'll write a blog post
and advertise on python-win32 to ask for Windows people who perhaps
might at least be interested in contributing time. I will also
advertise (and maybe enhance) Brian Curtin's how-to doc on Windows
Python core development... which I can't quite lay my hands on at
the moment. Hopefully we can lower the perceived entry-bar for
contribution at different levels.

TJG

From mail at timgolden.me.uk  Wed Aug  4 10:36:25 2010
From: mail at timgolden.me.uk (Tim Golden)
Date: Wed, 04 Aug 2010 09:36:25 +0100
Subject: [Python-Dev] Windows
In-Reply-To: <4C58EDDE.6050009@gmail.com>
References: <i3aeij$146$1@dough.gmane.org> <4C58EDDE.6050009@gmail.com>
Message-ID: <4C592689.6030904@timgolden.me.uk>

On 04/08/2010 05:34, Mark Hammond wrote:
> On 4/08/2010 11:08 AM, Steve Holden wrote:
>> It's a little disappointing to discover that despite the relatively
>> large number of developers who have received MSDN licenses from
>> Microsoft, none if us have the time to make sure that the buildbots are
>> green for the 2.6.6 release.
>>
>> I wonder if anyone can think of a way we can get some Windows skillz
>> into the group that could assist at ties like this. Some brainstorming
>> might find a way through.
>
> I never go looking at the buildbots to look for problems - maybe some
> way of explicitly bringing such failures to peoples attention would be
> good

Agree with that. This page looks hopeful:

   http://www.python.org/dev/buildbot/

with Atom/RSS feeds and an XML-RPC interface. I've subscribed to the
RSS feeed which is -- from my perspective -- quite noisy. One could
do something with the xml-rpc according to this:

   http://buildbot.net/buildbot/docs/0.7.11/#XMLRPC-server

but does anyone know how easy it would be use setup a mail notifier
to go to a specific Python mailing list on failure? I've looked at
mail.python.org and Googled around and I can't see something which
already does this, but I'm very happy to be wrong...

There seems to be some previous discussion:

   http://mail.python.org/pipermail/python-dev/2006-October/069617.html

but no sign of an outcome.

TJG

From solipsis at pitrou.net  Wed Aug  4 11:16:13 2010
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 4 Aug 2010 11:16:13 +0200
Subject: [Python-Dev] Looking after the buildbots (in general)
References: <i3aeij$146$1@dough.gmane.org>
Message-ID: <20100804111613.4e1273f7@pitrou.net>

On Tue, 03 Aug 2010 21:08:31 -0400
Steve Holden <steve at holdenweb.com> wrote:
> It's a little disappointing to discover that despite the relatively
> large number of developers who have received MSDN licenses from
> Microsoft, none if us have the time to make sure that the buildbots are
> green for the 2.6.6 release.

I think the issue is that many core developers don't have the reflex
to check buildbot state after they commit some changes (or at least
on a regular, say weekly, basis), and so gradually the buildbots have
a tendency to turn from green to red, one after another.

From time to time, a couple of "motivated" core developers (David, Ezio,
Mark, Florent...) try to fix the situation by diagnosing all pending
buildbot issues. It's a time-consuming task (because it's harder to
diagnose problems when you aren't the one who introduced them), and it's
somehow thankless and unmotivating (you'd rather work on your own
issues rather than fix bugs introduced by others).

Windows only exacerbates the problem because the aforementioned
"motivated" core developers aren't necessary knowledgeable enough to
write a fix, or even understand the problem.

I would advocate a system were people are encouraged to take
responsibility of the problems they introduce when committing changes.
Of course, there are sometimes situations where it's not possible
(triggering platform-specific oddities, for example).

Regards

Antoine.



From ezio.melotti at gmail.com  Wed Aug  4 11:34:35 2010
From: ezio.melotti at gmail.com (Ezio Melotti)
Date: Wed, 04 Aug 2010 12:34:35 +0300
Subject: [Python-Dev] Windows
In-Reply-To: <4C592689.6030904@timgolden.me.uk>
References: <i3aeij$146$1@dough.gmane.org> <4C58EDDE.6050009@gmail.com>
	<4C592689.6030904@timgolden.me.uk>
Message-ID: <4C59342B.5070703@gmail.com>

  On 04/08/2010 11.36, Tim Golden wrote:
> On 04/08/2010 05:34, Mark Hammond wrote:
>> On 4/08/2010 11:08 AM, Steve Holden wrote:
>>> It's a little disappointing to discover that despite the relatively
>>> large number of developers who have received MSDN licenses from
>>> Microsoft, none if us have the time to make sure that the buildbots are
>>> green for the 2.6.6 release.
>>>
>>> I wonder if anyone can think of a way we can get some Windows skillz
>>> into the group that could assist at ties like this. Some brainstorming
>>> might find a way through.
>>
>> I never go looking at the buildbots to look for problems - maybe some
>> way of explicitly bringing such failures to peoples attention would be
>> good
>
> Agree with that. This page looks hopeful:
>
>   http://www.python.org/dev/buildbot/
>
> with Atom/RSS feeds and an XML-RPC interface. I've subscribed to the
> RSS feeed which is -- from my perspective -- quite noisy. One could
> do something with the xml-rpc according to this:
>
>   http://buildbot.net/buildbot/docs/0.7.11/#XMLRPC-server
>
> but does anyone know how easy it would be use setup a mail notifier
> to go to a specific Python mailing list on failure? I've looked at
> mail.python.org and Googled around and I can't see something which
> already does this, but I'm very happy to be wrong...
>
> There seems to be some previous discussion:
>
>   http://mail.python.org/pipermail/python-dev/2006-October/069617.html
>
> but no sign of an outcome.
>
> TJG
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/ezio.melotti%40gmail.com
>

FWIW there's also http://code.google.com/p/bbreport/source/checkout
We were planning to use bbreport to create weekly summary and mail them 
to python-dev, but someone should write some code (I could do that but 
it's quite low in my to-do list) and make it run once a week.

Best Regards,
Ezio Melotti

From dirkjan at ochtman.nl  Wed Aug  4 11:42:18 2010
From: dirkjan at ochtman.nl (Dirkjan Ochtman)
Date: Wed, 4 Aug 2010 11:42:18 +0200
Subject: [Python-Dev] Looking after the buildbots (in general)
In-Reply-To: <20100804111613.4e1273f7@pitrou.net>
References: <i3aeij$146$1@dough.gmane.org> <20100804111613.4e1273f7@pitrou.net>
Message-ID: <AANLkTincr3fX1eCt+-H+yau4ZgbYNpfepw6HAX=BPhFp@mail.gmail.com>

On Wed, Aug 4, 2010 at 11:16, Antoine Pitrou <solipsis at pitrou.net> wrote:
> I would advocate a system were people are encouraged to take
> responsibility of the problems they introduce when committing changes.
> Of course, there are sometimes situations where it's not possible
> (triggering platform-specific oddities, for example).

They might not be able to diagnose the problems, or fix them, but I
think they should still take responsibility until handed over
explicitly to someone else who knows the failing platform, right?

It should be relatively straightforward to have some process send
email to authors of checkins that have created new failures.

Cheers,

Dirkjan

From ncoghlan at gmail.com  Wed Aug  4 12:08:28 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 4 Aug 2010 20:08:28 +1000
Subject: [Python-Dev] Looking after the buildbots (in general)
In-Reply-To: <AANLkTincr3fX1eCt+-H+yau4ZgbYNpfepw6HAX=BPhFp@mail.gmail.com>
References: <i3aeij$146$1@dough.gmane.org> <20100804111613.4e1273f7@pitrou.net>
	<AANLkTincr3fX1eCt+-H+yau4ZgbYNpfepw6HAX=BPhFp@mail.gmail.com>
Message-ID: <AANLkTinOfRjTG9vJi0dRe2axqNxFp+9k=r8xCaO10aJZ@mail.gmail.com>

On Wed, Aug 4, 2010 at 7:42 PM, Dirkjan Ochtman <dirkjan at ochtman.nl> wrote:
> On Wed, Aug 4, 2010 at 11:16, Antoine Pitrou <solipsis at pitrou.net> wrote:
>> I would advocate a system were people are encouraged to take
>> responsibility of the problems they introduce when committing changes.
>> Of course, there are sometimes situations where it's not possible
>> (triggering platform-specific oddities, for example).
>
> They might not be able to diagnose the problems, or fix them, but I
> think they should still take responsibility until handed over
> explicitly to someone else who knows the failing platform, right?
>
> It should be relatively straightforward to have some process send
> email to authors of checkins that have created new failures.

I believe that was the original intent, but the buildbot set generated
too many false alarms (due to flaky tests which would fail
intermittently) so it was never implemented.

However, I believe the 3.x tests have had most of that flakiness
eliminated (dropping bsddb helped greatly on that front), so it should
be feasible to restore that feature for the stable buildbot set on the
Py3k branch.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From p.f.moore at gmail.com  Wed Aug  4 12:48:30 2010
From: p.f.moore at gmail.com (Paul Moore)
Date: Wed, 4 Aug 2010 11:48:30 +0100
Subject: [Python-Dev] (Windows) buildbots on 3.x
Message-ID: <AANLkTimK48CRc53_ymurdA+aKo-EDFLM5Nxra5poGWfK@mail.gmail.com>

On 3 August 2010 20:30, Barry Warsaw <barry at python.org> wrote:
> Brian is looking at Windows now (the buildbots are
> a sad and sorry story).

There seems to be something distinctly wrong with the 3.x buildbots. A
lot of test failures and timeouts. At first I assumed it was my
buildslave going flaky (again :-() but it only affects the 3.x branch,
and it seems to be hitting more than just my slave. From what I'm
seeing, it's often test_io that's getting stalled and then sitting
round until it times out. (But as I say, it's not obviously related to
problems on my box as it's happening to others - see
http://www.python.org/dev//buildbot/builders/x86%20XP-4%203.x/builds/2652
for example - and it's not happening on other branches).

I haven't had time to look into it (and probably won't in the next few
days) but it might be worth a look at some point if anyone has the
time & inclination.

Paul.

From steve at holdenweb.com  Wed Aug  4 13:37:57 2010
From: steve at holdenweb.com (Steve Holden)
Date: Wed, 04 Aug 2010 07:37:57 -0400
Subject: [Python-Dev] Windows
In-Reply-To: <4C591B79.9020407@timgolden.me.uk>
References: <i3aeij$146$1@dough.gmane.org> <4C591B79.9020407@timgolden.me.uk>
Message-ID: <4C595115.4040500@holdenweb.com>

On 8/4/2010 3:49 AM, Tim Golden wrote:
> On 04/08/2010 02:08, Steve Holden wrote:
>> It's a little disappointing to discover that despite the relatively
>> large number of developers who have received MSDN licenses from
>> Microsoft, none if us have the time to make sure that the buildbots are
>> green for the 2.6.6 release.
>>
>> I wonder if anyone can think of a way we can get some Windows skillz
>> into the group that could assist at ties like this. Some brainstorming
>> might find a way through.
> 
> My own problem is just the amount of ramp-up time (as a proportion of
> my own available time) to get hold of a problem even when I see it.
> (Speaking here in the more general sense of fixing Windows-related
> Python bugs).
> 
> As one who has benefitted from the MSDN largesse I am certainly
> conscious of
> the responsibility to contribute benefits back to the Python community.
> On the basis that I'm far more likely to watch a buildbot which I actually
> administer, I have recently nudged my sysadmins here to see if they can
> make good on their promise to find me a spare server to use as a buildbot.
> 
> I have watched the buildbot pages occasionally, especially when I see
> Windows-related commits going in, but several times "red" buildbots
> have turned out to be -- apparently -- environmental / local issues
> unrelated to commits. Obviously I could/should have contacted the
> buildbot owner to at least inform him or her that something was amiss.
> But somehow at that point one's technical enthusiasm for fixing a
> problem diminishes when it's not clear that there *is* a problem.
> (Grumble, grumble, mutter, mutter... :) )
> 
> While we'd certainly benefit from more Windows skills, we'd probably
> benefit more from people who have more *time* to look at Windows
> issues. OK; to propose something concrete: I'll write a blog post
> and advertise on python-win32 to ask for Windows people who perhaps
> might at least be interested in contributing time. I will also
> advertise (and maybe enhance) Brian Curtin's how-to doc on Windows
> Python core development... which I can't quite lay my hands on at
> the moment. Hopefully we can lower the perceived entry-bar for
> contribution at different levels.
> 
Thanks, Tim. When I said "more Windows skillz" I should, of course, have
said "more people with time to apply their Windows skillz". I imagine if
we get some new blood in we can get them access to MSDN licenses should
they be needed.

regards
 Steve
-- 
Steve Holden           +1 571 484 6266   +1 800 494 3119
DjangoCon US September 7-9, 2010    http://djangocon.us/
See Python Video!       http://python.mirocommunity.org/
Holden Web LLC                 http://www.holdenweb.com/


From richard at python.org  Wed Aug  4 13:43:31 2010
From: richard at python.org (Richard Jones)
Date: Wed, 4 Aug 2010 21:43:31 +1000
Subject: [Python-Dev] (Windows) buildbots on 3.x
In-Reply-To: <AANLkTimK48CRc53_ymurdA+aKo-EDFLM5Nxra5poGWfK@mail.gmail.com>
References: <AANLkTimK48CRc53_ymurdA+aKo-EDFLM5Nxra5poGWfK@mail.gmail.com>
Message-ID: <AANLkTi=K55K-Bv6wsfUMs5XYMBcdK50biLTgL74ZuiKw@mail.gmail.com>

On Wed, Aug 4, 2010 at 8:48 PM, Paul Moore <p.f.moore at gmail.com> wrote:
> On 3 August 2010 20:30, Barry Warsaw <barry at python.org> wrote:
>> Brian is looking at Windows now (the buildbots are
>> a sad and sorry story).
>
> There seems to be something distinctly wrong with the 3.x buildbots. A
> lot of test failures and timeouts. At first I assumed it was my
> buildslave going flaky (again :-() but it only affects the 3.x branch,
> and it seems to be hitting more than just my slave. From what I'm
> seeing, it's often test_io that's getting stalled and then sitting
> round until it times out.

I'm also quite confused by the test_smtpd failures that pop up on some
of the test runs that I've had absolutely no luck reproducing locally
under OS X or Solaris.


      Richard

From steve at holdenweb.com  Wed Aug  4 13:44:46 2010
From: steve at holdenweb.com (Steve Holden)
Date: Wed, 04 Aug 2010 07:44:46 -0400
Subject: [Python-Dev] Looking after the buildbots (in general)
In-Reply-To: <AANLkTinOfRjTG9vJi0dRe2axqNxFp+9k=r8xCaO10aJZ@mail.gmail.com>
References: <i3aeij$146$1@dough.gmane.org>
	<20100804111613.4e1273f7@pitrou.net>	<AANLkTincr3fX1eCt+-H+yau4ZgbYNpfepw6HAX=BPhFp@mail.gmail.com>
	<AANLkTinOfRjTG9vJi0dRe2axqNxFp+9k=r8xCaO10aJZ@mail.gmail.com>
Message-ID: <i3bjrg$8sm$1@dough.gmane.org>

On 8/4/2010 6:08 AM, Nick Coghlan wrote:
> On Wed, Aug 4, 2010 at 7:42 PM, Dirkjan Ochtman <dirkjan at ochtman.nl> wrote:
>> On Wed, Aug 4, 2010 at 11:16, Antoine Pitrou <solipsis at pitrou.net> wrote:
>>> I would advocate a system were people are encouraged to take
>>> responsibility of the problems they introduce when committing changes.
>>> Of course, there are sometimes situations where it's not possible
>>> (triggering platform-specific oddities, for example).
>>
>> They might not be able to diagnose the problems, or fix them, but I
>> think they should still take responsibility until handed over
>> explicitly to someone else who knows the failing platform, right?
>>
>> It should be relatively straightforward to have some process send
>> email to authors of checkins that have created new failures.
> 
> I believe that was the original intent, but the buildbot set generated
> too many false alarms (due to flaky tests which would fail
> intermittently) so it was never implemented.
> 
> However, I believe the 3.x tests have had most of that flakiness
> eliminated (dropping bsddb helped greatly on that front), so it should
> be feasible to restore that feature for the stable buildbot set on the
> Py3k branch.

I think that would be good, and an attractive extra benefit of the work
that's gone into the tests recently. The point of having the buildbots
was to alert people to when one of their changes breaks a build they
weren't able to test on. Indeed I seem to remember at one time I used to
see "blame" emails, which were not always accurate (I haven't been
subscribed to checkins for a while due to volume of other mail). That's
a heavy load to carry for a new developer, so having defined people to
go to for help on strange platforms would be useful. Assuming, of
course, that such people can be identified.

I'm well aware that developers have limits on the time they can spend on
Python. There's no blame here, just a wish to improve the process and
ensure that the Windows platform doesn't become the "poor relation".

Thanks to everyone for the positive responses.

regards
 Steve
-- 
Steve Holden           +1 571 484 6266   +1 800 494 3119
DjangoCon US September 7-9, 2010    http://djangocon.us/
See Python Video!       http://python.mirocommunity.org/
Holden Web LLC                 http://www.holdenweb.com/


From solipsis at pitrou.net  Wed Aug  4 14:05:43 2010
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 04 Aug 2010 14:05:43 +0200
Subject: [Python-Dev] [python-committers]  (Windows) buildbots on 3.x
In-Reply-To: <AANLkTi=K55K-Bv6wsfUMs5XYMBcdK50biLTgL74ZuiKw@mail.gmail.com>
References: <AANLkTimK48CRc53_ymurdA+aKo-EDFLM5Nxra5poGWfK@mail.gmail.com>
	<AANLkTi=K55K-Bv6wsfUMs5XYMBcdK50biLTgL74ZuiKw@mail.gmail.com>
Message-ID: <1280923543.3231.0.camel@localhost.localdomain>

Le mercredi 04 ao?t 2010 ? 21:43 +1000, Richard Jones a ?crit :
> On Wed, Aug 4, 2010 at 8:48 PM, Paul Moore <p.f.moore at gmail.com> wrote:
> > On 3 August 2010 20:30, Barry Warsaw <barry at python.org> wrote:
> >> Brian is looking at Windows now (the buildbots are
> >> a sad and sorry story).
> >
> > There seems to be something distinctly wrong with the 3.x buildbots. A
> > lot of test failures and timeouts. At first I assumed it was my
> > buildslave going flaky (again :-() but it only affects the 3.x branch,
> > and it seems to be hitting more than just my slave. From what I'm
> > seeing, it's often test_io that's getting stalled and then sitting
> > round until it times out.
> 
> I'm also quite confused by the test_smtpd failures that pop up on some
> of the test runs that I've had absolutely no luck reproducing locally
> under OS X or Solaris.

It happens when running test_smtplib before test_smtpb:

$./python -m test.regrtest -v test_smtplib test_smtpd

== CPython 3.2a1+ (py3k:83711M, Aug 4 2010, 13:23:20) [GCC 4.4.3]
==   Linux-2.6.33.5-desktop-2mnb-x86_64-with-mandrake-2010.1-Official
==   /home/antoine/py3k/__svn__/build/test_python_13320
[1/2] test_smtplib
testBasic1 (test.test_smtplib.GeneralTests) ... ok
testBasic2 (test.test_smtplib.GeneralTests) ... ok
testLocalHostName (test.test_smtplib.GeneralTests) ... ok
testTimeoutDefault (test.test_smtplib.GeneralTests) ... ok
testTimeoutNone (test.test_smtplib.GeneralTests) ... ok
testTimeoutValue (test.test_smtplib.GeneralTests) ... ok
testBasic (test.test_smtplib.DebuggingServerTests) ... ok
testHELP (test.test_smtplib.DebuggingServerTests) ... ok
testNOOP (test.test_smtplib.DebuggingServerTests) ... ok
testNotImplemented (test.test_smtplib.DebuggingServerTests) ... ok
testRSET (test.test_smtplib.DebuggingServerTests) ... ok
testSecondHELO (test.test_smtplib.DebuggingServerTests) ... ok
testSend (test.test_smtplib.DebuggingServerTests) ... ok
testVRFY (test.test_smtplib.DebuggingServerTests) ... ok
testNonnumericPort (test.test_smtplib.NonConnectingTests) ... ok
testNotConnected (test.test_smtplib.NonConnectingTests) ... ok
testFailingHELO (test.test_smtplib.BadHELOServerTests) ... ok
testAUTH_CRAM_MD5 (test.test_smtplib.SMTPSimTests) ... ok
testAUTH_LOGIN (test.test_smtplib.SMTPSimTests) ... ok
testAUTH_PLAIN (test.test_smtplib.SMTPSimTests) ... ok
testBasic (test.test_smtplib.SMTPSimTests) ... ok
testEHLO (test.test_smtplib.SMTPSimTests) ... ok
testEXPN (test.test_smtplib.SMTPSimTests) ... ok
testVRFY (test.test_smtplib.SMTPSimTests) ... ok

----------------------------------------------------------------------
Ran 24 tests in 0.107s

OK
[2/2] test_smtpd
test_process_message_unimplemented (test.test_smtpd.SMTPDServerTest) ... FAIL
test_DATA_syntax (test.test_smtpd.SMTPDChannelTest) ... FAIL
test_EHLO_not_implemented (test.test_smtpd.SMTPDChannelTest) ... FAIL
test_HELO (test.test_smtpd.SMTPDChannelTest) ... FAIL
test_HELO_bad_syntax (test.test_smtpd.SMTPDChannelTest) ... FAIL
test_HELO_duplicate (test.test_smtpd.SMTPDChannelTest) ... FAIL
test_MAIL_chevrons (test.test_smtpd.SMTPDChannelTest) ... FAIL
test_MAIL_missing_from (test.test_smtpd.SMTPDChannelTest) ... FAIL
test_MAIL_syntax (test.test_smtpd.SMTPDChannelTest) ... FAIL
test_NOOP (test.test_smtpd.SMTPDChannelTest) ... FAIL
test_NOOP_bad_syntax (test.test_smtpd.SMTPDChannelTest) ... FAIL
test_QUIT (test.test_smtpd.SMTPDChannelTest) ... FAIL
test_QUIT_arg_ignored (test.test_smtpd.SMTPDChannelTest) ... FAIL
test_RCPT_syntax (test.test_smtpd.SMTPDChannelTest) ... FAIL
test_RSET (test.test_smtpd.SMTPDChannelTest) ... ERROR
test_RSET_syntax (test.test_smtpd.SMTPDChannelTest) ... FAIL
test_attribute_deprecations (test.test_smtpd.SMTPDChannelTest) ... ok
test_bad_state (test.test_smtpd.SMTPDChannelTest) ... ok
test_broken_connect (test.test_smtpd.SMTPDChannelTest) ... ok
test_data_dialog (test.test_smtpd.SMTPDChannelTest) ... FAIL
test_data_transparency_section_4_5_2 (test.test_smtpd.SMTPDChannelTest) ... FAIL
test_manual_status (test.test_smtpd.SMTPDChannelTest) ... FAIL
test_missing_data (test.test_smtpd.SMTPDChannelTest) ... FAIL
test_multiple_RCPT (test.test_smtpd.SMTPDChannelTest) ... ERROR
test_need_MAIL (test.test_smtpd.SMTPDChannelTest) ... FAIL
test_need_RCPT (test.test_smtpd.SMTPDChannelTest) ... FAIL
test_nested_MAIL (test.test_smtpd.SMTPDChannelTest) ... FAIL
test_server_accept (test.test_smtpd.SMTPDChannelTest) ... ok

======================================================================
ERROR: test_RSET (test.test_smtpd.SMTPDChannelTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/test/test_smtpd.py", line 212, in test_RSET
    self.assertEqual(self.server.messages[0],
IndexError: list index out of range

======================================================================
ERROR: test_multiple_RCPT (test.test_smtpd.SMTPDChannelTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/test/test_smtpd.py", line 192, in test_multiple_RCPT
    self.assertEqual(self.server.messages[-1],
IndexError: list index out of range

======================================================================
FAIL: test_process_message_unimplemented (test.test_smtpd.SMTPDServerTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/test/test_smtpd.py", line 45, in test_process_message_unimplemented
    self.assertRaises(NotImplementedError, write_line, b'spam\r\n.\r\n')
AssertionError: NotImplementedError not raised by write_line

======================================================================
FAIL: test_DATA_syntax (test.test_smtpd.SMTPDChannelTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/test/test_smtpd.py", line 177, in test_DATA_syntax
    self.assertEqual(self.channel.socket.last, b'501 Syntax: DATA\r\n')
AssertionError: b'250 Ok\r\n' != b'501 Syntax: DATA\r\n'

======================================================================
FAIL: test_EHLO_not_implemented (test.test_smtpd.SMTPDChannelTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/test/test_smtpd.py", line 80, in test_EHLO_not_implemented
    b'502 Error: command "EHLO" not implemented\r\n')
AssertionError: b'502 Error: command "199" not implemented\r\n' != b'502 Error: command "EHLO" not implemented\r\n'

======================================================================
FAIL: test_HELO (test.test_smtpd.SMTPDChannelTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/test/test_smtpd.py", line 86, in test_HELO
    '250 {}\r\n'.format(name).encode('ascii'))
AssertionError: b'502 Error: command "199" not implemented\r\n' != b'250 \r\n'

======================================================================
FAIL: test_HELO_bad_syntax (test.test_smtpd.SMTPDChannelTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/test/test_smtpd.py", line 91, in test_HELO_bad_syntax
    b'501 Syntax: HELO hostname\r\n')
AssertionError: b'502 Error: command "199" not implemented\r\n' != b'501 Syntax: HELO hostname\r\n'

======================================================================
FAIL: test_HELO_duplicate (test.test_smtpd.SMTPDChannelTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/test/test_smtpd.py", line 97, in test_HELO_duplicate
    b'503 Duplicate HELO/EHLO\r\n')
AssertionError: b'250 \r\n' != b'503 Duplicate HELO/EHLO\r\n'

======================================================================
FAIL: test_MAIL_chevrons (test.test_smtpd.SMTPDChannelTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/test/test_smtpd.py", line 139, in test_MAIL_chevrons
    self.assertEqual(self.channel.socket.last, b'250 Ok\r\n')
AssertionError: b'502 Error: command "199" not implemented\r\n' != b'250 Ok\r\n'

======================================================================
FAIL: test_MAIL_missing_from (test.test_smtpd.SMTPDChannelTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/test/test_smtpd.py", line 135, in test_MAIL_missing_from
    b'501 Syntax: MAIL FROM:<address>\r\n')
AssertionError: b'502 Error: command "199" not implemented\r\n' != b'501 Syntax: MAIL FROM:<address>\r\n'

======================================================================
FAIL: test_MAIL_syntax (test.test_smtpd.SMTPDChannelTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/test/test_smtpd.py", line 130, in test_MAIL_syntax
    b'501 Syntax: MAIL FROM:<address>\r\n')
AssertionError: b'502 Error: command "199" not implemented\r\n' != b'501 Syntax: MAIL FROM:<address>\r\n'

======================================================================
FAIL: test_NOOP (test.test_smtpd.SMTPDChannelTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/test/test_smtpd.py", line 101, in test_NOOP
    self.assertEqual(self.channel.socket.last, b'250 Ok\r\n')
AssertionError: b'502 Error: command "199" not implemented\r\n' != b'250 Ok\r\n'

======================================================================
FAIL: test_NOOP_bad_syntax (test.test_smtpd.SMTPDChannelTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/test/test_smtpd.py", line 106, in test_NOOP_bad_syntax
    b'501 Syntax: NOOP\r\n')
AssertionError: b'502 Error: command "199" not implemented\r\n' != b'501 Syntax: NOOP\r\n'

======================================================================
FAIL: test_QUIT (test.test_smtpd.SMTPDChannelTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/test/test_smtpd.py", line 110, in test_QUIT
    self.assertEqual(self.channel.socket.last, b'221 Bye\r\n')
AssertionError: b'502 Error: command "199" not implemented\r\n' != b'221 Bye\r\n'

======================================================================
FAIL: test_QUIT_arg_ignored (test.test_smtpd.SMTPDChannelTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/test/test_smtpd.py", line 114, in test_QUIT_arg_ignored
    self.assertEqual(self.channel.socket.last, b'221 Bye\r\n')
AssertionError: b'502 Error: command "199" not implemented\r\n' != b'221 Bye\r\n'

======================================================================
FAIL: test_RCPT_syntax (test.test_smtpd.SMTPDChannelTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/test/test_smtpd.py", line 157, in test_RCPT_syntax
    b'501 Syntax: RCPT TO: <address>\r\n')
AssertionError: b'250 Ok\r\n' != b'501 Syntax: RCPT TO: <address>\r\n'

======================================================================
FAIL: test_RSET_syntax (test.test_smtpd.SMTPDChannelTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/test/test_smtpd.py", line 217, in test_RSET_syntax
    self.assertEqual(self.channel.socket.last, b'501 Syntax: RSET\r\n')
AssertionError: b'502 Error: command "199" not implemented\r\n' != b'501 Syntax: RSET\r\n'

======================================================================
FAIL: test_data_dialog (test.test_smtpd.SMTPDChannelTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/test/test_smtpd.py", line 161, in test_data_dialog
    self.assertEqual(self.channel.socket.last, b'250 Ok\r\n')
AssertionError: b'502 Error: command "199" not implemented\r\n' != b'250 Ok\r\n'

======================================================================
FAIL: test_data_transparency_section_4_5_2 (test.test_smtpd.SMTPDChannelTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/test/test_smtpd.py", line 184, in test_data_transparency_section_4_5_2
    self.assertEqual(self.channel.received_data, '.')
AssertionError: '' != '.'
+ .

======================================================================
FAIL: test_manual_status (test.test_smtpd.SMTPDChannelTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/test/test_smtpd.py", line 201, in test_manual_status
    self.assertEqual(self.channel.socket.last, b'250 Okish\r\n')
AssertionError: b'354 End data with <CR><LF>.<CR><LF>\r\n' != b'250 Okish\r\n'

======================================================================
FAIL: test_missing_data (test.test_smtpd.SMTPDChannelTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/test/test_smtpd.py", line 75, in test_missing_data
    b'500 Error: bad syntax\r\n')
AssertionError: b'502 Error: command "199" not implemented\r\n' != b'500 Error: bad syntax\r\n'

======================================================================
FAIL: test_need_MAIL (test.test_smtpd.SMTPDChannelTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/test/test_smtpd.py", line 125, in test_need_MAIL
    b'503 Error: need MAIL command\r\n')
AssertionError: b'502 Error: command "199" not implemented\r\n' != b'503 Error: need MAIL command\r\n'

======================================================================
FAIL: test_need_RCPT (test.test_smtpd.SMTPDChannelTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/test/test_smtpd.py", line 151, in test_need_RCPT
    b'503 Error: need RCPT command\r\n')
AssertionError: b'250 Ok\r\n' != b'503 Error: need RCPT command\r\n'

======================================================================
FAIL: test_nested_MAIL (test.test_smtpd.SMTPDChannelTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/test/test_smtpd.py", line 145, in test_nested_MAIL
    b'503 Error: nested MAIL command\r\n')
AssertionError: b'250 Ok\r\n' != b'503 Error: nested MAIL command\r\n'

----------------------------------------------------------------------
Ran 28 tests in 0.013s

FAILED (failures=22, errors=2)
test test_smtpd failed -- multiple errors occurred
1 test OK.
1 test failed:
    test_smtpd



From richard at python.org  Wed Aug  4 14:28:09 2010
From: richard at python.org (Richard Jones)
Date: Wed, 4 Aug 2010 22:28:09 +1000
Subject: [Python-Dev] [python-committers]  (Windows) buildbots on 3.x
In-Reply-To: <1280923543.3231.0.camel@localhost.localdomain>
References: <AANLkTimK48CRc53_ymurdA+aKo-EDFLM5Nxra5poGWfK@mail.gmail.com>
	<AANLkTi=K55K-Bv6wsfUMs5XYMBcdK50biLTgL74ZuiKw@mail.gmail.com>
	<1280923543.3231.0.camel@localhost.localdomain>
Message-ID: <AANLkTinRhDKQNZhCZFJ=_u=N7H5R1q7fFvLf69GGq7mo@mail.gmail.com>

On Wed, Aug 4, 2010 at 10:05 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> It happens when running test_smtplib before test_smtpb:

Aha! Thanks for the clue. I've checked in a fix.


      Richard

From lukasz at langa.pl  Wed Aug  4 15:39:16 2010
From: lukasz at langa.pl (=?utf-8?Q?=C5=81ukasz_Langa?=)
Date: Wed, 4 Aug 2010 15:39:16 +0200
Subject: [Python-Dev] #2651 - KeyError does not round trip strings
Message-ID: <96448358-C3F6-4012-94FC-CAAE8D0F18D9@langa.pl>

Hi guys,
there's this 2 year old bug about making strings passed to KeyError round trip:

http://bugs.python.org/issue2651

There are three things I like you to present opinions on.



0. The moratorium.

Based on the old 2.x patch there I created a new one for py3k. It's been reviewed and it was actually quite close to it being committed when Georg reminded us that there's this moratorium situation. So, please -1 that change here or on the issue if you think it should be stopped until the moratorium ends. Georg, Antoine and Michael Foord seem to be +1 on it despite the moratorium. (guys, please correct me if I'm wrong)



1. The patch makes KeyError behave analogically to IOError so that the first arg is now a message and the second is the actual key.

>>> raise KeyError("Key not found", "a Scotsman on a horse")
Traceback (most recent call last):
...
KeyError: 'Key not found: a Scotsman on a horse'

This is backwards incompatible (which has been addressed for the stdlib in the patch). Now, for non-empty e.args, the key is stored in e.args[-1] whereas it used to in e.args[0]. We could swap the args to make it backwards compatible but then we lose consistency with IOError and the issue on the tracker was originally targetting consistency.



2. Some people suggest adding e.key to KeyError. I like the idea but in my opinion currently it is not implementable in a reliable way.

a) if the party raising the exception does not pass any arguments, what would the expected behaviour of e.key be? `None` is a valid key so returning this can be misleading.

b) if the party raising the exception passes one argument, how do we know it's a key and not a message? Take for instance "Set is empty" and such. Presenting e.key = "Set is empty" is just wrong.

c) if the party raising the exception passes two arguments, we already know which one is the key. So in this case it would work well but at the same time it would be somewhat redundant.

Antoine and Michael Foord suggest that we simply do a "best-effort thing" and present `None` if no args are passed and always treat the only argument as a key. It would be consistent with what's IOError is doing at the moment. I'm on the fence here myself.

-- 
Best regards,
?ukasz Langa
tel. +48 791 080 144
WWW http://lukasz.langa.pl/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100804/a7cef384/attachment-0001.html>

From solipsis at pitrou.net  Wed Aug  4 15:53:55 2010
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 4 Aug 2010 15:53:55 +0200
Subject: [Python-Dev] #2651 - KeyError does not round trip strings
References: <96448358-C3F6-4012-94FC-CAAE8D0F18D9@langa.pl>
Message-ID: <20100804155355.11b5d00a@pitrou.net>

On Wed, 4 Aug 2010 15:39:16 +0200
?ukasz Langa <lukasz at langa.pl> wrote:
> 1. The patch makes KeyError behave analogically to IOError so that the first arg is now a message and the second is the actual key.
> 
> >>> raise KeyError("Key not found", "a Scotsman on a horse")
> Traceback (most recent call last):
> ...
> KeyError: 'Key not found: a Scotsman on a horse'

I suppose you mean
  KeyError: Key not found: 'a Scotsman on a horse'
?

> This is backwards incompatible (which has been addressed for the stdlib in the patch). Now, for non-empty e.args, the key is stored in e.args[-1] whereas it used to in e.args[0]. We could swap the args to make it backwards compatible but then we lose consistency with IOError and the issue on the tracker was originally targetting consistency.

I don't think consistency with IOError is very important. IOError and
KeyError have basically nothing in common.

> 2. Some people suggest adding e.key to KeyError. I like the idea but in my opinion currently it is not implementable in a reliable way.
> 
> a) if the party raising the exception does not pass any arguments, what would the expected behaviour of e.key be? `None` is a valid key so returning this can be misleading.
> 
> b) if the party raising the exception passes one argument, how do we know it's a key and not a message? Take for instance "Set is empty" and such. Presenting e.key = "Set is empty" is just wrong.

As per your patch, all builtins will have been converted to the two
argument form, though, and arguably they are the most common source of
KeyErrors.

> c) if the party raising the exception passes two arguments, we already know which one is the key. So in this case it would work well but at the same time it would be somewhat redundant.

What do you mean? You can certainly use e.args[-1] but it's an ugly and
highly unintuitive notation. I wish the args stuff could die peacefully.

Regards

Antoine.



From fdrake at acm.org  Wed Aug  4 16:23:02 2010
From: fdrake at acm.org (Fred Drake)
Date: Wed, 4 Aug 2010 10:23:02 -0400
Subject: [Python-Dev] #2651 - KeyError does not round trip strings
In-Reply-To: <96448358-C3F6-4012-94FC-CAAE8D0F18D9@langa.pl>
References: <96448358-C3F6-4012-94FC-CAAE8D0F18D9@langa.pl>
Message-ID: <AANLkTikEA9v2fNo_1HHH162C391bNM9DpoPnJzEj1Dy9@mail.gmail.com>

2010/8/4 ?ukasz Langa <lukasz at langa.pl>:
> 1. The patch makes KeyError behave analogically to IOError so that the first
> arg is now a message and the second is the actual key.

I agree with Antoine; there's no point to this.

> 2. Some people suggest adding e.key to KeyError. I like the idea but in my
> opinion currently it is not implementable in a reliable way.

This is interesting and useful.

I'd be really happy to see e.key be present if the key is known
(because it was specifically provided to the constructor:
KeyError(key=...)), or not present if the key isn't known.  (The idea
is much less interesting if code can't distinguish between the
key-is-known and the key-not-known cases.)

The runtime and standard library should be adjusted to provide the key
whenever possible, of course.

Though I doubt this would break anything, we've lived without this
long enough that the it doesn't represent a sufficient failing that
the moratorium should be broken.  It can wait.


? -Fred

--
Fred L. Drake, Jr.? ? <fdrake at gmail.com>
"A storm broke loose in my mind."? --Albert Einstein

From barry at python.org  Wed Aug  4 16:41:36 2010
From: barry at python.org (Barry Warsaw)
Date: Wed, 4 Aug 2010 10:41:36 -0400
Subject: [Python-Dev] [Python-checkins] r83704 - in
 python/branches/release26-maint: Lib/asyncore.py Misc/ACKS Misc/NEWS
In-Reply-To: <20100804085838.3D95EEE994@mail.python.org>
References: <20100804085838.3D95EEE994@mail.python.org>
Message-ID: <20100804104136.76a30782@heresy>

Hi Giampaolo,

Now that we're in quasi-freeze for 2.6.6 final, this is the kind of change I'd
like to review before backporting.  In this case, I'll let it through, but
please check with me first next time.

And thanks for your work!
-Barry

On Aug 04, 2010, at 10:58 AM, giampaolo.rodola wrote:

>Author: giampaolo.rodola
>Date: Wed Aug  4 10:58:38 2010
>New Revision: 83704
>
>Log:
>Merged revisions 83703 via svnmerge from 
>svn+ssh://pythondev at svn.python.org/python/branches/release27-maint
>
>........
>  r83703 | giampaolo.rodola | 2010-08-04 10:35:25 +0200 (mer, 04 ago
> 2010) | 1 line 
>  fix issue #2944: asyncore doesn't handle connection refused
> correctly (patch by Alexander Shigin)
>........
>
>
>Modified:
>   python/branches/release26-maint/   (props changed)
>   python/branches/release26-maint/Lib/asyncore.py
>   python/branches/release26-maint/Misc/ACKS
>   python/branches/release26-maint/Misc/NEWS
>
>Modified: python/branches/release26-maint/Lib/asyncore.py
>==============================================================================
>--- python/branches/release26-maint/Lib/asyncore.py	(original)
>+++ python/branches/release26-maint/Lib/asyncore.py	Wed Aug  4
>10:58:38 2010 @@ -422,8 +422,11 @@
>             self.handle_read()
> 
>     def handle_connect_event(self):
>-        self.connected = True
>+        err = self.socket.getsockopt(socket.SOL_SOCKET,
>socket.SO_ERROR)
>+        if err != 0:
>+            raise socket.error(err, _strerror(err))
>         self.handle_connect()
>+        self.connected = True
> 
>     def handle_write_event(self):
>         if self.accepting:
>
>Modified: python/branches/release26-maint/Misc/ACKS
>==============================================================================
>--- python/branches/release26-maint/Misc/ACKS	(original)
>+++ python/branches/release26-maint/Misc/ACKS	Wed Aug  4
>10:58:38 2010 @@ -817,3 +817,4 @@
> Peter ?strand
> Jesse Noller
> Fredrik H??rd
>+Alexander Shigin
>
>Modified: python/branches/release26-maint/Misc/NEWS
>==============================================================================
>--- python/branches/release26-maint/Misc/NEWS	(original)
>+++ python/branches/release26-maint/Misc/NEWS	Wed Aug  4
>10:58:38 2010 @@ -89,6 +89,8 @@
> Library
> -------
> 
>+- Issue #2944: asyncore doesn't handle connection refused correctly.
>+
> - Issue #8447: Make distutils.sysconfig follow symlinks in the path to
>   the interpreter executable.  This fixes a failure of
> test_httpservers on OS X.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100804/7658ff02/attachment.pgp>

From rob.cliffe at btinternet.com  Wed Aug  4 16:45:45 2010
From: rob.cliffe at btinternet.com (Rob Cliffe)
Date: Wed, 4 Aug 2010 15:45:45 +0100
Subject: [Python-Dev] Drive suffix
Message-ID: <BD56C6C87FA349439871663F1FB3307D@robslaptop>

Is there a way of determining the suffix used after a drive letter to denote a drive, e.g. on Windows the ":" in r"C:\Dir\Subdir\File.Ext" ?  Or is the colon so universal that it is considered unnecessary?  Should it be in the os module somewhere (as far as I can tell, it isn't, although every other kind of file path component separator seems to be) ?
Best wishes
Rob Cliffe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100804/3ac2187d/attachment.html>

From barry at python.org  Wed Aug  4 16:48:10 2010
From: barry at python.org (Barry Warsaw)
Date: Wed, 4 Aug 2010 10:48:10 -0400
Subject: [Python-Dev] Windows
In-Reply-To: <i3aeij$146$1@dough.gmane.org>
References: <i3aeij$146$1@dough.gmane.org>
Message-ID: <20100804104810.4197e870@heresy>

On Aug 03, 2010, at 09:08 PM, Steve Holden wrote:

>It's a little disappointing to discover that despite the relatively
>large number of developers who have received MSDN licenses from
>Microsoft, none if us have the time to make sure that the buildbots are
>green for the 2.6.6 release.

Should note that I did try to build Python using my MSDN license for Windows 7
and Visual Studio 2010.  I only had an hour or so to attempt it, and did not
succeed, though I think I got as far as trying to properly situate various
dependent libraries (sqlite, ssl).

If anybody's successfully navigated the twisty maze, would you be able to
write something up on the wiki to describe the steps you've taken?

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100804/e1c406c0/attachment.pgp>

From barry at python.org  Wed Aug  4 16:51:19 2010
From: barry at python.org (Barry Warsaw)
Date: Wed, 4 Aug 2010 10:51:19 -0400
Subject: [Python-Dev] Looking after the buildbots (in general)
In-Reply-To: <20100804111613.4e1273f7@pitrou.net>
References: <i3aeij$146$1@dough.gmane.org> <20100804111613.4e1273f7@pitrou.net>
Message-ID: <20100804105119.6ae19dc3@heresy>

On Aug 04, 2010, at 11:16 AM, Antoine Pitrou wrote:

>I think the issue is that many core developers don't have the reflex
>to check buildbot state after they commit some changes (or at least
>on a regular, say weekly, basis), and so gradually the buildbots have
>a tendency to turn from green to red, one after another.

I'd classify this as a failure of the tools, not of the developers.  These
post-commit verification steps should be proactive, and scream really loud (or
even prevent future commits) until everything is green again.  Buildbots
themselves can be unstable, so this may or may not be workable, and changing
any of this will take valuable volunteer time.  It's also unsexy work.

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100804/57fb2fbd/attachment.pgp>

From brian.curtin at gmail.com  Wed Aug  4 17:00:12 2010
From: brian.curtin at gmail.com (Brian Curtin)
Date: Wed, 4 Aug 2010 10:00:12 -0500
Subject: [Python-Dev] Windows
In-Reply-To: <20100804104810.4197e870@heresy>
References: <i3aeij$146$1@dough.gmane.org>
	<20100804104810.4197e870@heresy>
Message-ID: <AANLkTimN7uW_ZA-esR5UTv-Pp-342WjzL7OL46pJV1e5@mail.gmail.com>

On Wed, Aug 4, 2010 at 09:48, Barry Warsaw <barry at python.org> wrote:

> On Aug 03, 2010, at 09:08 PM, Steve Holden wrote:
>
> >It's a little disappointing to discover that despite the relatively
> >large number of developers who have received MSDN licenses from
> >Microsoft, none if us have the time to make sure that the buildbots are
> >green for the 2.6.6 release.
>
> Should note that I did try to build Python using my MSDN license for
> Windows 7
> and Visual Studio 2010.  I only had an hour or so to attempt it, and did
> not
> succeed, though I think I got as far as trying to properly situate various
> dependent libraries (sqlite, ssl).
>
> If anybody's successfully navigated the twisty maze, would you be able to
> write something up on the wiki to describe the steps you've taken?
>
> -Barry


I can expand the dev setup guide I wrote for the PSF Sprints to include the
third-party stuff, then try to get that in wider circulation. I currently
gloss over it to get a first-time contributor up and running quickly (since
someone's first look into core dev is unlikely to be fixing sqlite).

I haven't tried the current codebase on VS2010 yet, but it's on my todo
list.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100804/3104b951/attachment.html>

From phd at phd.pp.ru  Wed Aug  4 17:08:20 2010
From: phd at phd.pp.ru (Oleg Broytman)
Date: Wed, 4 Aug 2010 19:08:20 +0400
Subject: [Python-Dev] w32 drive separator (was: Drive suffix)
In-Reply-To: <BD56C6C87FA349439871663F1FB3307D@robslaptop>
References: <BD56C6C87FA349439871663F1FB3307D@robslaptop>
Message-ID: <20100804150820.GA31476@phd.pp.ru>

On Wed, Aug 04, 2010 at 03:45:45PM +0100, Rob Cliffe wrote:
> Is there a way of determining the suffix used after a drive letter to denote a drive, e.g. on Windows the ":" in r"C:\Dir\Subdir\File.Ext" ?  Or is the colon so universal that it is considered unnecessary?  Should it be in the os module somewhere (as far as I can tell, it isn't, although every other kind of file path component separator seems to be) ?

   It's not universal, exactly opposite - it's specific to a rare graphic
environment produced by a small company based in Redmond... sorry, I cannot
resist. (-:
   Because of this (':' being too specific) it's built right into ntpath.py
- the module that 'os' module imports when it finds itself running inside
that graphic environment. It's used as a character constant all over
ntpath.py without any name.

Oleg.
-- 
     Oleg Broytman            http://phd.pp.ru/            phd at phd.pp.ru
           Programmers don't die, they just GOSUB without RETURN.

From guido at python.org  Wed Aug  4 17:10:43 2010
From: guido at python.org (Guido van Rossum)
Date: Wed, 4 Aug 2010 08:10:43 -0700
Subject: [Python-Dev] Drive suffix
In-Reply-To: <BD56C6C87FA349439871663F1FB3307D@robslaptop>
References: <BD56C6C87FA349439871663F1FB3307D@robslaptop>
Message-ID: <AANLkTi=7_bewh97XuvM21sW-V7GNTMCq6_KLhVHoT5CF@mail.gmail.com>

It's Windows specific syntax and always a colon. Use
os.path.splitdrive() to parse it. I don't think there's a need to add
a named constant for it (you're the first to ask, in my memory).

On Wed, Aug 4, 2010 at 7:45 AM, Rob Cliffe <rob.cliffe at btinternet.com> wrote:
> Is there a way of determining the suffix used after a drive letter to denote
> a drive, e.g. on Windows the ":" in r"C:\Dir\Subdir\File.Ext" ?? Or is the
> colon so universal that it is considered unnecessary?? Should it be in the
> os module somewhere (as far as I can tell, it isn't, although every other
> kind of file path component separator seems to be) ?

-- 
--Guido van Rossum (python.org/~guido)

From exarkun at twistedmatrix.com  Wed Aug  4 17:15:53 2010
From: exarkun at twistedmatrix.com (exarkun at twistedmatrix.com)
Date: Wed, 04 Aug 2010 15:15:53 -0000
Subject: [Python-Dev] Looking after the buildbots (in general)
In-Reply-To: <20100804105119.6ae19dc3@heresy>
References: <i3aeij$146$1@dough.gmane.org> <20100804111613.4e1273f7@pitrou.net>
	<20100804105119.6ae19dc3@heresy>
Message-ID: <20100804151553.2305.954819342.divmod.xquotient.83@localhost.localdomain>

On 02:51 pm, barry at python.org wrote:
>On Aug 04, 2010, at 11:16 AM, Antoine Pitrou wrote:
>>I think the issue is that many core developers don't have the reflex
>>to check buildbot state after they commit some changes (or at least
>>on a regular, say weekly, basis), and so gradually the buildbots have
>>a tendency to turn from green to red, one after another.
>
>I'd classify this as a failure of the tools, not of the developers. 
>These
>post-commit verification steps should be proactive, and scream really 
>loud (or
>even prevent future commits) until everything is green again. 
>Buildbots
>themselves can be unstable, so this may or may not be workable, and 
>changing
>any of this will take valuable volunteer time.  It's also unsexy work.

How hard is it to look at a web page?

Jean-Paul

From fuzzyman at voidspace.org.uk  Wed Aug  4 17:17:41 2010
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Wed, 04 Aug 2010 16:17:41 +0100
Subject: [Python-Dev] Looking after the buildbots (in general)
In-Reply-To: <20100804151553.2305.954819342.divmod.xquotient.83@localhost.localdomain>
References: <i3aeij$146$1@dough.gmane.org>
	<20100804111613.4e1273f7@pitrou.net>	<20100804105119.6ae19dc3@heresy>
	<20100804151553.2305.954819342.divmod.xquotient.83@localhost.localdomain>
Message-ID: <4C598495.4090609@voidspace.org.uk>

On 04/08/2010 16:15, exarkun at twistedmatrix.com wrote:
> On 02:51 pm, barry at python.org wrote:
>> On Aug 04, 2010, at 11:16 AM, Antoine Pitrou wrote:
>>> I think the issue is that many core developers don't have the reflex
>>> to check buildbot state after they commit some changes (or at least
>>> on a regular, say weekly, basis), and so gradually the buildbots have
>>> a tendency to turn from green to red, one after another.
>>
>> I'd classify this as a failure of the tools, not of the developers. 
>> These
>> post-commit verification steps should be proactive, and scream really 
>> loud (or
>> even prevent future commits) until everything is green again. Buildbots
>> themselves can be unstable, so this may or may not be workable, and 
>> changing
>> any of this will take valuable volunteer time. It's also unsexy work.
>
> How hard is it to look at a web page?

The hard part is remembering.

Michael

>
> Jean-Paul
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at 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/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (?BOGUS AGREEMENTS?) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.



From prologic at shortcircuit.net.au  Wed Aug  4 17:18:31 2010
From: prologic at shortcircuit.net.au (James Mills)
Date: Thu, 5 Aug 2010 01:18:31 +1000
Subject: [Python-Dev] Drive suffix
In-Reply-To: <AANLkTi=7_bewh97XuvM21sW-V7GNTMCq6_KLhVHoT5CF@mail.gmail.com>
References: <BD56C6C87FA349439871663F1FB3307D@robslaptop>
	<AANLkTi=7_bewh97XuvM21sW-V7GNTMCq6_KLhVHoT5CF@mail.gmail.com>
Message-ID: <AANLkTimCndKJycuE52+zND4bGk6NEe1i35Mb_P8ZvEzp@mail.gmail.com>

On Thu, Aug 5, 2010 at 1:10 AM, Guido van Rossum <guido at python.org> wrote:
> It's Windows specific syntax and always a colon. Use
> os.path.splitdrive() to parse it. I don't think there's a need to add
> a named constant for it (you're the first to ask, in my memory).

HI Guido, I'm not a windows user or developer, but I concur.
When I was reading this post I kept thinking to myself that Windows
is one of the only Operating Systems with a File system that reuiqres
this [A-Z]:\ syntax. All sensible POSIX systems I know and File Systems
all mount various other media on "mount points". *shrug*

--James

-- 
-- James Mills
--
-- "Problems are solved by method"

From rob.cliffe at btinternet.com  Wed Aug  4 17:19:36 2010
From: rob.cliffe at btinternet.com (Rob Cliffe)
Date: Wed, 4 Aug 2010 16:19:36 +0100
Subject: [Python-Dev] Drive suffix
References: <BD56C6C87FA349439871663F1FB3307D@robslaptop>
	<AANLkTi=7_bewh97XuvM21sW-V7GNTMCq6_KLhVHoT5CF@mail.gmail.com>
Message-ID: <C937871F81D7411289819D5D627A27C1@robslaptop>

Thanks for your replies, guys.
As it happens, what sparked the question was trying to determine in a 
platform-independent way whether a path consisted of a bare drive 
specification (e.g. "C:").  I guess
    os.path.splitdrive(MyPath)[1] == ""
takes care of that.
Rob Cliffe


----- Original Message ----- 
From: "Guido van Rossum" <guido at python.org>
To: "Rob Cliffe" <rob.cliffe at btinternet.com>
Cc: "Python-Dev" <python-dev at python.org>
Sent: Wednesday, August 04, 2010 4:10 PM
Subject: Re: [Python-Dev] Drive suffix


It's Windows specific syntax and always a colon. Use
os.path.splitdrive() to parse it. I don't think there's a need to add
a named constant for it (you're the first to ask, in my memory).

On Wed, Aug 4, 2010 at 7:45 AM, Rob Cliffe <rob.cliffe at btinternet.com> 
wrote:
> Is there a way of determining the suffix used after a drive letter to 
> denote
> a drive, e.g. on Windows the ":" in r"C:\Dir\Subdir\File.Ext" ? Or is the
> colon so universal that it is considered unnecessary? Should it be in the
> os module somewhere (as far as I can tell, it isn't, although every other
> kind of file path component separator seems to be) ?

-- 
--Guido van Rossum (python.org/~guido) 


From p.f.moore at gmail.com  Wed Aug  4 17:25:38 2010
From: p.f.moore at gmail.com (Paul Moore)
Date: Wed, 4 Aug 2010 16:25:38 +0100
Subject: [Python-Dev] Windows
In-Reply-To: <4C591B79.9020407@timgolden.me.uk>
References: <i3aeij$146$1@dough.gmane.org> <4C591B79.9020407@timgolden.me.uk>
Message-ID: <AANLkTinJA9Xxvmn42GLhHuKA7MYtWe_vBi5k0_wP6Enz@mail.gmail.com>

On 4 August 2010 08:49, Tim Golden <mail at timgolden.me.uk> wrote:
> I have watched the buildbot pages occasionally, especially when I see
> Windows-related commits going in, but several times "red" buildbots
> have turned out to be -- apparently -- environmental / local issues
> unrelated to commits. Obviously I could/should have contacted the
> buildbot owner to at least inform him or her that something was amiss.
> But somehow at that point one's technical enthusiasm for fixing a
> problem diminishes when it's not clear that there *is* a problem.
> (Grumble, grumble, mutter, mutter... :) )

I agree that having a buildbot of your own to administer tends to
encourage you to be more aware of issues - it certainly did for me.
However, from my own experience, the Windows buildbot environment is
fairly flaky, and I spend far too much time killing "stuck" python
processes and VS JIT debugger processes, rather than actually usefully
debugging real issues. (And I don't know of any way of finding out
where the stuck processes came from or what they were doing at the
time that they got stuck, so all I can do is kill them...)

I don't have any Windows sysadmin experience, so I struggle to fix
these types of problem, and doing so often takes up all the time that
would otherwise go to areas where I *could* do some good, digging into
genuine issues :-(

I don't really have any answer to this problem right now. Is it
possible to set up a local buildslave-like environment (so I can run
the test suite on my development PC without needing to set up access
and register that PC as a temporary buildslave, which wouldn't be
practical for me)? If I can get an environment where I can run the
tests as I need and debug them in place, I might be able to work on
improving the reliability of things.

Paul.

From p.f.moore at gmail.com  Wed Aug  4 17:28:15 2010
From: p.f.moore at gmail.com (Paul Moore)
Date: Wed, 4 Aug 2010 16:28:15 +0100
Subject: [Python-Dev] [python-committers]  (Windows) buildbots on 3.x
In-Reply-To: <1280923543.3231.0.camel@localhost.localdomain>
References: <AANLkTimK48CRc53_ymurdA+aKo-EDFLM5Nxra5poGWfK@mail.gmail.com>
	<AANLkTi=K55K-Bv6wsfUMs5XYMBcdK50biLTgL74ZuiKw@mail.gmail.com>
	<1280923543.3231.0.camel@localhost.localdomain>
Message-ID: <AANLkTi=5bxYwuaTDaQ6QXBrxJcW85W+b-nmvqajM3Sor@mail.gmail.com>

On 4 August 2010 13:05, Antoine Pitrou <solipsis at pitrou.net> wrote:

>> I'm also quite confused by the test_smtpd failures that pop up on some
>> of the test runs that I've had absolutely no luck reproducing locally
>> under OS X or Solaris.
>
> It happens when running test_smtplib before test_smtpb:

Nice! How did you work that out? I'd like to learn how to diagnose
this sort of thing, because it seems to come up a lot, and I'm not
much use at the moment :-)

Paul.

From barry at python.org  Wed Aug  4 17:31:40 2010
From: barry at python.org (Barry Warsaw)
Date: Wed, 4 Aug 2010 11:31:40 -0400
Subject: [Python-Dev] Looking after the buildbots (in general)
In-Reply-To: <20100804151553.2305.954819342.divmod.xquotient.83@localhost.localdomain>
References: <i3aeij$146$1@dough.gmane.org> <20100804111613.4e1273f7@pitrou.net>
	<20100804105119.6ae19dc3@heresy>
	<20100804151553.2305.954819342.divmod.xquotient.83@localhost.localdomain>
Message-ID: <20100804113140.03aaf80b@heresy>

On Aug 04, 2010, at 03:15 PM, exarkun at twistedmatrix.com wrote:

>On 02:51 pm, barry at python.org wrote:
>>On Aug 04, 2010, at 11:16 AM, Antoine Pitrou wrote:
>>>I think the issue is that many core developers don't have the reflex
>>>to check buildbot state after they commit some changes (or at least
>>>on a regular, say weekly, basis), and so gradually the buildbots have
>>>a tendency to turn from green to red, one after another.
>>
>>I'd classify this as a failure of the tools, not of the developers.
>>>These post-commit verification steps should be proactive, and scream
>>>really >loud (or
>>even prevent future commits) until everything is green again.
>>>Buildbots themselves can be unstable, so this may or may not be
>>>workable, and >changing
>>any of this will take valuable volunteer time.  It's also unsexy work.
>
>How hard is it to look at a web page?

That's not the right question :)

The real questions are: how hard is it to remember how to find the appropriate
web page, how hard is it to know which buildbots are *actually* stable enough
to rely on, how hard is it to decipher the results to know what they're
telling you?

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100804/b856fb37/attachment.pgp>

From solipsis at pitrou.net  Wed Aug  4 17:33:22 2010
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 04 Aug 2010 17:33:22 +0200
Subject: [Python-Dev] [python-committers]  (Windows) buildbots on 3.x
In-Reply-To: <AANLkTi=5bxYwuaTDaQ6QXBrxJcW85W+b-nmvqajM3Sor@mail.gmail.com>
References: <AANLkTimK48CRc53_ymurdA+aKo-EDFLM5Nxra5poGWfK@mail.gmail.com>
	<AANLkTi=K55K-Bv6wsfUMs5XYMBcdK50biLTgL74ZuiKw@mail.gmail.com>
	<1280923543.3231.0.camel@localhost.localdomain>
	<AANLkTi=5bxYwuaTDaQ6QXBrxJcW85W+b-nmvqajM3Sor@mail.gmail.com>
Message-ID: <1280936002.3231.4.camel@localhost.localdomain>

Le mercredi 04 ao?t 2010 ? 16:28 +0100, Paul Moore a ?crit :
> On 4 August 2010 13:05, Antoine Pitrou <solipsis at pitrou.net> wrote:
> 
> >> I'm also quite confused by the test_smtpd failures that pop up on some
> >> of the test runs that I've had absolutely no luck reproducing locally
> >> under OS X or Solaris.
> >
> > It happens when running test_smtplib before test_smtpb:
> 
> Nice! How did you work that out? I'd like to learn how to diagnose
> this sort of thing, because it seems to come up a lot, and I'm not
> much use at the moment :-)

I took a quick look at test_smtpd, and the one possibly fishy thing that
stood out was the monkeypatching of the socket module using
test.mock_socket. Since monkeypatching typically goes wrong when several
people monkeypatch the same thing, and the other test.mock_socket user
is test_smtplib, and since the buildbots run tests in random order
(rather than in deterministic alphabetic order), I simply tried to run
test_smtplib before test_smtpd.

Regards

Antoine.



From exarkun at twistedmatrix.com  Wed Aug  4 17:38:29 2010
From: exarkun at twistedmatrix.com (exarkun at twistedmatrix.com)
Date: Wed, 04 Aug 2010 15:38:29 -0000
Subject: [Python-Dev] Looking after the buildbots (in general)
In-Reply-To: <4C598495.4090609@voidspace.org.uk>
References: <i3aeij$146$1@dough.gmane.org> <20100804111613.4e1273f7@pitrou.net>
	<20100804105119.6ae19dc3@heresy>
	<20100804151553.2305.954819342.divmod.xquotient.83@localhost.localdomain>
	<4C598495.4090609@voidspace.org.uk>
Message-ID: <20100804153829.2305.658460851.divmod.xquotient.84@localhost.localdomain>

On 03:17 pm, fuzzyman at voidspace.org.uk wrote:
>On 04/08/2010 16:15, exarkun at twistedmatrix.com wrote:
>>On 02:51 pm, barry at python.org wrote:
>>>On Aug 04, 2010, at 11:16 AM, Antoine Pitrou wrote:
>>>>I think the issue is that many core developers don't have the reflex
>>>>to check buildbot state after they commit some changes (or at least
>>>>on a regular, say weekly, basis), and so gradually the buildbots 
>>>>have
>>>>a tendency to turn from green to red, one after another.
>>>
>>>I'd classify this as a failure of the tools, not of the developers. 
>>>These
>>>post-commit verification steps should be proactive, and scream really 
>>>loud (or
>>>even prevent future commits) until everything is green again. 
>>>Buildbots
>>>themselves can be unstable, so this may or may not be workable, and 
>>>changing
>>>any of this will take valuable volunteer time. It's also unsexy work.
>>
>>How hard is it to look at a web page?
>
>The hard part is remembering.

Seems to be setting the bar awfully low for Python developers.

Jean-Paul

From steve at holdenweb.com  Wed Aug  4 17:38:53 2010
From: steve at holdenweb.com (Steve Holden)
Date: Wed, 04 Aug 2010 11:38:53 -0400
Subject: [Python-Dev] Windows
In-Reply-To: <AANLkTimN7uW_ZA-esR5UTv-Pp-342WjzL7OL46pJV1e5@mail.gmail.com>
References: <i3aeij$146$1@dough.gmane.org>	<20100804104810.4197e870@heresy>
	<AANLkTimN7uW_ZA-esR5UTv-Pp-342WjzL7OL46pJV1e5@mail.gmail.com>
Message-ID: <4C59898D.9040106@holdenweb.com>

On 8/4/2010 11:00 AM, Brian Curtin wrote:
> On Wed, Aug 4, 2010 at 09:48, Barry Warsaw <barry at python.org
> <mailto:barry at python.org>> wrote:
> 
>     On Aug 03, 2010, at 09:08 PM, Steve Holden wrote:
> 
>     >It's a little disappointing to discover that despite the relatively
>     >large number of developers who have received MSDN licenses from
>     >Microsoft, none if us have the time to make sure that the buildbots are
>     >green for the 2.6.6 release.
> 
>     Should note that I did try to build Python using my MSDN license for
>     Windows 7
>     and Visual Studio 2010.  I only had an hour or so to attempt it, and
>     did not
>     succeed, though I think I got as far as trying to properly situate
>     various
>     dependent libraries (sqlite, ssl).
> 
>     If anybody's successfully navigated the twisty maze, would you be
>     able to
>     write something up on the wiki to describe the steps you've taken?
> 
>     -Barry
> 
> 
> I can expand the dev setup guide I wrote for the PSF Sprints to include
> the third-party stuff, then try to get that in wider circulation. I
> currently gloss over it to get a first-time contributor up and running
> quickly (since someone's first look into core dev is unlikely to be
> fixing sqlite).
> 
> I haven't tried the current codebase on VS2010 yet, but it's on my todo
> list.
> 
I think that could be incredibly useful. I've tried building Windows
Pythons in the past and stalled because I didn't have enough familiarity
with the VS environment.

regards
 Steve

-- 
Steve Holden           +1 571 484 6266   +1 800 494 3119
DjangoCon US September 7-9, 2010    http://djangocon.us/
See Python Video!       http://python.mirocommunity.org/
Holden Web LLC                 http://www.holdenweb.com/


From steve at holdenweb.com  Wed Aug  4 17:39:03 2010
From: steve at holdenweb.com (Steve Holden)
Date: Wed, 04 Aug 2010 11:39:03 -0400
Subject: [Python-Dev] Windows
In-Reply-To: <AANLkTimN7uW_ZA-esR5UTv-Pp-342WjzL7OL46pJV1e5@mail.gmail.com>
References: <i3aeij$146$1@dough.gmane.org>	<20100804104810.4197e870@heresy>
	<AANLkTimN7uW_ZA-esR5UTv-Pp-342WjzL7OL46pJV1e5@mail.gmail.com>
Message-ID: <4C598997.4040007@holdenweb.com>

On 8/4/2010 11:00 AM, Brian Curtin wrote:
> On Wed, Aug 4, 2010 at 09:48, Barry Warsaw <barry at python.org
> <mailto:barry at python.org>> wrote:
> 
>     On Aug 03, 2010, at 09:08 PM, Steve Holden wrote:
> 
>     >It's a little disappointing to discover that despite the relatively
>     >large number of developers who have received MSDN licenses from
>     >Microsoft, none if us have the time to make sure that the buildbots are
>     >green for the 2.6.6 release.
> 
>     Should note that I did try to build Python using my MSDN license for
>     Windows 7
>     and Visual Studio 2010.  I only had an hour or so to attempt it, and
>     did not
>     succeed, though I think I got as far as trying to properly situate
>     various
>     dependent libraries (sqlite, ssl).
> 
>     If anybody's successfully navigated the twisty maze, would you be
>     able to
>     write something up on the wiki to describe the steps you've taken?
> 
>     -Barry
> 
> 
> I can expand the dev setup guide I wrote for the PSF Sprints to include
> the third-party stuff, then try to get that in wider circulation. I
> currently gloss over it to get a first-time contributor up and running
> quickly (since someone's first look into core dev is unlikely to be
> fixing sqlite).
> 
> I haven't tried the current codebase on VS2010 yet, but it's on my todo
> list.
> 
I think that could be incredibly useful. I've tried building Windows
Pythons in the past and stalled because I didn't have enough familiarity
with the VS environment.

regards
 Steve

-- 
Steve Holden           +1 571 484 6266   +1 800 494 3119
DjangoCon US September 7-9, 2010    http://djangocon.us/
See Python Video!       http://python.mirocommunity.org/
Holden Web LLC                 http://www.holdenweb.com/


From mail at timgolden.me.uk  Wed Aug  4 17:49:28 2010
From: mail at timgolden.me.uk (Tim Golden)
Date: Wed, 04 Aug 2010 16:49:28 +0100
Subject: [Python-Dev] Windows
In-Reply-To: <4C59898D.9040106@holdenweb.com>
References: <i3aeij$146$1@dough.gmane.org>	<20100804104810.4197e870@heresy>	<AANLkTimN7uW_ZA-esR5UTv-Pp-342WjzL7OL46pJV1e5@mail.gmail.com>
	<4C59898D.9040106@holdenweb.com>
Message-ID: <4C598C08.3070207@timgolden.me.uk>

On 04/08/2010 16:38, Steve Holden wrote:
> On 8/4/2010 11:00 AM, Brian Curtin wrote:
>> On Wed, Aug 4, 2010 at 09:48, Barry Warsaw<barry at python.org
>> <mailto:barry at python.org>>  wrote:
>>
>>      On Aug 03, 2010, at 09:08 PM, Steve Holden wrote:
>>
>>      >It's a little disappointing to discover that despite the relatively
>>      >large number of developers who have received MSDN licenses from
>>      >Microsoft, none if us have the time to make sure that the buildbots are
>>      >green for the 2.6.6 release.
>>
>>      Should note that I did try to build Python using my MSDN license for
>>      Windows 7
>>      and Visual Studio 2010.  I only had an hour or so to attempt it, and
>>      did not
>>      succeed, though I think I got as far as trying to properly situate
>>      various
>>      dependent libraries (sqlite, ssl).
>>
>>      If anybody's successfully navigated the twisty maze, would you be
>>      able to
>>      write something up on the wiki to describe the steps you've taken?
>>
>>      -Barry
>>
>>
>> I can expand the dev setup guide I wrote for the PSF Sprints to include
>> the third-party stuff, then try to get that in wider circulation. I
>> currently gloss over it to get a first-time contributor up and running
>> quickly (since someone's first look into core dev is unlikely to be
>> fixing sqlite).
>>
>> I haven't tried the current codebase on VS2010 yet, but it's on my todo
>> list.
>>
> I think that could be incredibly useful. I've tried building Windows
> Pythons in the past and stalled because I didn't have enough familiarity
> with the VS environment.

Brian: could you remind us where that doc is, please? I've lost track of it.

In broad terms it's not too hard to get going once you've installed 
VS[*]; I've
rebuild several different fresh Python checkouts several times today 
while these
issues have been discussed, and generally it's a question of:

cd py3k (or whatever)
tools\buildbot\externals.bat
cd py3k\pcbuild
env
build -d
rt -d

and you're done and tested.

That said, I seem to be having build issues with ssl on 2.7 which I'll
try to look into. But the technique is fairly straightforward.

TJG

[*] And a small clutter of other tools for certain bits

From kristjan at ccpgames.com  Wed Aug  4 17:53:49 2010
From: kristjan at ccpgames.com (=?iso-8859-1?Q?Kristj=E1n_Valur_J=F3nsson?=)
Date: Wed, 4 Aug 2010 15:53:49 +0000
Subject: [Python-Dev] pickle output not unique
In-Reply-To: <4C588097.9090108@v.loewis.de>
References: <930F189C8A437347B80DF2C156F7EC7F0B8D41B488@exchis.ccp.ad.local>
	<4C588097.9090108@v.loewis.de>
Message-ID: <930F189C8A437347B80DF2C156F7EC7F0B8D41B65E@exchis.ccp.ad.local>



> -----Original Message-----
> From: "Martin v. L?wis" [mailto:martin at v.loewis.de]
> Sent: 3. ?g?st 2010 20:48
> To: Kristj?n Valur J?nsson
> Cc: Python-Dev
> Subject: Re: [Python-Dev] pickle output not unique
> 
> > I just wanted to point this out.  We'll attempt some local
> workarounds
> > here, but it should otherwise be simple to modify pickling to
> optionally
> > turn off this optimization and always generate the same output
> > irrespective of the internal reference counts of the objects.
> 
> I think there are many other instances where values that compare equal
> pickle differently in Python. By relying on this property for hashing,
> you are really operating on thin ice.

Well, it is not _that_ dangerous.  It just causes cache misses when they wouldn't be expected.
But since this has been brought up and dismissed in issue 8738, I won't pursue this further.

K

From curt at hagenlocher.org  Wed Aug  4 17:54:40 2010
From: curt at hagenlocher.org (Curt Hagenlocher)
Date: Wed, 4 Aug 2010 08:54:40 -0700
Subject: [Python-Dev] Windows
In-Reply-To: <AANLkTinJA9Xxvmn42GLhHuKA7MYtWe_vBi5k0_wP6Enz@mail.gmail.com>
References: <i3aeij$146$1@dough.gmane.org> <4C591B79.9020407@timgolden.me.uk>
	<AANLkTinJA9Xxvmn42GLhHuKA7MYtWe_vBi5k0_wP6Enz@mail.gmail.com>
Message-ID: <AANLkTi=OdjUD8eb7TP7O2G_D7AOFzKm-29osgpWPf-BD@mail.gmail.com>

On Wed, Aug 4, 2010 at 8:25 AM, Paul Moore <p.f.moore at gmail.com> wrote:
>
> However, from my own experience, the Windows buildbot environment is
> fairly flaky, and I spend far too much time killing "stuck" python
> processes and VS JIT debugger processes, rather than actually usefully
> debugging real issues.

I would turn off JIT debugging. On an unattended machine, it's more
annoying than useful.
http://msdn.microsoft.com/en-us/library/5hs4b7a6(VS.80).aspx

--
Curt Hagenlocher
curt at hagenlocher.org

From g.brandl at gmx.net  Wed Aug  4 17:53:11 2010
From: g.brandl at gmx.net (Georg Brandl)
Date: Wed, 04 Aug 2010 17:53:11 +0200
Subject: [Python-Dev] Looking after the buildbots (in general)
In-Reply-To: <20100804151553.2305.954819342.divmod.xquotient.83@localhost.localdomain>
References: <i3aeij$146$1@dough.gmane.org>
	<20100804111613.4e1273f7@pitrou.net>	<20100804105119.6ae19dc3@heresy>
	<20100804151553.2305.954819342.divmod.xquotient.83@localhost.localdomain>
Message-ID: <i3c2i5$322$1@dough.gmane.org>

Am 04.08.2010 17:15, schrieb exarkun at twistedmatrix.com:
> On 02:51 pm, barry at python.org wrote:
>>On Aug 04, 2010, at 11:16 AM, Antoine Pitrou wrote:
>>>I think the issue is that many core developers don't have the reflex
>>>to check buildbot state after they commit some changes (or at least
>>>on a regular, say weekly, basis), and so gradually the buildbots have
>>>a tendency to turn from green to red, one after another.
>>
>>I'd classify this as a failure of the tools, not of the developers. 
>>These
>>post-commit verification steps should be proactive, and scream really 
>>loud (or
>>even prevent future commits) until everything is green again. 
>>Buildbots
>>themselves can be unstable, so this may or may not be workable, and 
>>changing
>>any of this will take valuable volunteer time.  It's also unsexy work.
> 
> How hard is it to look at a web page?

The hard part is to know *when* to look.  As you might have noticed, the
Python test suite does not run in ten seconds, especially on some of the
buildbots -- it can take 1-2 there to complete.  So if you look too soon,
you won't see all the results, and usually the slow systems are the
interesting ones.

Now we could of course have a commit hook that counts down two hours and
then sends an email to the committer "Now look at the buildbot!"...

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.


From brian.curtin at gmail.com  Wed Aug  4 18:05:12 2010
From: brian.curtin at gmail.com (Brian Curtin)
Date: Wed, 4 Aug 2010 11:05:12 -0500
Subject: [Python-Dev] Windows
In-Reply-To: <4C598C08.3070207@timgolden.me.uk>
References: <i3aeij$146$1@dough.gmane.org> <20100804104810.4197e870@heresy>
	<AANLkTimN7uW_ZA-esR5UTv-Pp-342WjzL7OL46pJV1e5@mail.gmail.com>
	<4C59898D.9040106@holdenweb.com> <4C598C08.3070207@timgolden.me.uk>
Message-ID: <AANLkTikYTggbsobwSZN+pcX5Wv1AaqFoYccsyQh-Z6YG@mail.gmail.com>

On Wed, Aug 4, 2010 at 10:49, Tim Golden <mail at timgolden.me.uk> wrote:

> On 04/08/2010 16:38, Steve Holden wrote:
>
>> On 8/4/2010 11:00 AM, Brian Curtin wrote:
>>
>>> On Wed, Aug 4, 2010 at 09:48, Barry Warsaw<barry at python.org
>>> <mailto:barry at python.org>>  wrote:
>>>
>>>     On Aug 03, 2010, at 09:08 PM, Steve Holden wrote:
>>>
>>>     >It's a little disappointing to discover that despite the relatively
>>>     >large number of developers who have received MSDN licenses from
>>>     >Microsoft, none if us have the time to make sure that the buildbots
>>> are
>>>     >green for the 2.6.6 release.
>>>
>>>     Should note that I did try to build Python using my MSDN license for
>>>     Windows 7
>>>     and Visual Studio 2010.  I only had an hour or so to attempt it, and
>>>     did not
>>>     succeed, though I think I got as far as trying to properly situate
>>>     various
>>>     dependent libraries (sqlite, ssl).
>>>
>>>     If anybody's successfully navigated the twisty maze, would you be
>>>     able to
>>>     write something up on the wiki to describe the steps you've taken?
>>>
>>>     -Barry
>>>
>>>
>>> I can expand the dev setup guide I wrote for the PSF Sprints to include
>>> the third-party stuff, then try to get that in wider circulation. I
>>> currently gloss over it to get a first-time contributor up and running
>>> quickly (since someone's first look into core dev is unlikely to be
>>> fixing sqlite).
>>>
>>> I haven't tried the current codebase on VS2010 yet, but it's on my todo
>>> list.
>>>
>>>  I think that could be incredibly useful. I've tried building Windows
>> Pythons in the past and stalled because I didn't have enough familiarity
>> with the VS environment.
>>
>
> Brian: could you remind us where that doc is, please? I've lost track of
> it.
>
> In broad terms it's not too hard to get going once you've installed VS[*];
> I've
> rebuild several different fresh Python checkouts several times today while
> these
> issues have been discussed, and generally it's a question of:
>
> cd py3k (or whatever)
> tools\buildbot\externals.bat
> cd py3k\pcbuild
> env
> build -d
> rt -d
>
> and you're done and tested.
>
> That said, I seem to be having build issues with ssl on 2.7 which I'll
> try to look into. But the technique is fairly straightforward.
>
> TJG
>
> [*] And a small clutter of other tools for certain bits


http://docs.pythonsprints.com/core_development/beginners.html

Building ssl requires Perl and nasm, and gets completed as a post-build
step. I haven't done that in a while but it's documented in
PCBuild/readme.txt. That's the stuff I'll be adding to the above document.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100804/33596e80/attachment.html>

From alexander.belopolsky at gmail.com  Wed Aug  4 18:17:08 2010
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Wed, 4 Aug 2010 12:17:08 -0400
Subject: [Python-Dev] pickle output not unique
In-Reply-To: <930F189C8A437347B80DF2C156F7EC7F0B8D41B65E@exchis.ccp.ad.local>
References: <930F189C8A437347B80DF2C156F7EC7F0B8D41B488@exchis.ccp.ad.local>
	<4C588097.9090108@v.loewis.de>
	<930F189C8A437347B80DF2C156F7EC7F0B8D41B65E@exchis.ccp.ad.local>
Message-ID: <AANLkTinLYa68+H+9cAApsmzHSk8E79TimUR6xndWL_46@mail.gmail.com>

2010/8/4 Kristj?n Valur J?nsson <kristjan at ccpgames.com>:
..
> Well, it is not _that_ dangerous. ?It just causes cache misses when they wouldn't be expected.
> But since this has been brought up and dismissed in issue 8738, I won't pursue this further.

Don't read too much from the "dismissal" of issue 8738.  I will be
happy to reopen it if there are ideas on how to improve the situation.
  For example, it may be helpful to document whether the situation
improved in 3.x and whether pickletools.optimize produces more
consistent pickles.  If you change your mind, please leave a note on
the issue.

From dstanek at dstanek.com  Wed Aug  4 18:21:21 2010
From: dstanek at dstanek.com (David Stanek)
Date: Wed, 4 Aug 2010 12:21:21 -0400
Subject: [Python-Dev] Looking after the buildbots (in general)
In-Reply-To: <i3c2i5$322$1@dough.gmane.org>
References: <i3aeij$146$1@dough.gmane.org> <20100804111613.4e1273f7@pitrou.net>
	<20100804105119.6ae19dc3@heresy>
	<20100804151553.2305.954819342.divmod.xquotient.83@localhost.localdomain>
	<i3c2i5$322$1@dough.gmane.org>
Message-ID: <AANLkTinkPd2VjA0N3nMbLpO4hVqmpj-Of=F1u_We57j5@mail.gmail.com>

On Wed, Aug 4, 2010 at 11:53 AM, Georg Brandl <g.brandl at gmx.net> wrote:
>
> The hard part is to know *when* to look. ?As you might have noticed, the
> Python test suite does not run in ten seconds, especially on some of the
> buildbots -- it can take 1-2 there to complete. ?So if you look too soon,
> you won't see all the results, and usually the slow systems are the
> interesting ones.
>
> Now we could of course have a commit hook that counts down two hours and
> then sends an email to the committer "Now look at the buildbot!"...
>

Why not have buildbot slaves email the committer when their change
broke the build. I realize that if you break 25 slaves it would not be
pleasant to receive 25 emails, but I've had worse things happen. Or
buildbot slaves can report failures to a mailing list or IRC chat.

-- 
David
blog: http://www.traceback.org
twitter: http://twitter.com/dstanek

From exarkun at twistedmatrix.com  Wed Aug  4 18:42:25 2010
From: exarkun at twistedmatrix.com (exarkun at twistedmatrix.com)
Date: Wed, 04 Aug 2010 16:42:25 -0000
Subject: [Python-Dev] Looking after the buildbots (in general)
In-Reply-To: <20100804113140.03aaf80b@heresy>
References: <i3aeij$146$1@dough.gmane.org> <20100804111613.4e1273f7@pitrou.net>
	<20100804105119.6ae19dc3@heresy>
	<20100804151553.2305.954819342.divmod.xquotient.83@localhost.localdomain>
	<20100804113140.03aaf80b@heresy>
Message-ID: <20100804164225.2305.654532857.divmod.xquotient.91@localhost.localdomain>

On 03:31 pm, barry at python.org wrote:
>On Aug 04, 2010, at 03:15 PM, exarkun at twistedmatrix.com wrote:
>>On 02:51 pm, barry at python.org wrote:
>>>On Aug 04, 2010, at 11:16 AM, Antoine Pitrou wrote:
>>>>I think the issue is that many core developers don't have the reflex
>>>>to check buildbot state after they commit some changes (or at least
>>>>on a regular, say weekly, basis), and so gradually the buildbots 
>>>>have
>>>>a tendency to turn from green to red, one after another.
>>>
>>>I'd classify this as a failure of the tools, not of the developers.
>>>>These post-commit verification steps should be proactive, and scream
>>>>really >loud (or
>>>even prevent future commits) until everything is green again.
>>>>Buildbots themselves can be unstable, so this may or may not be
>>>>workable, and >changing
>>>any of this will take valuable volunteer time.  It's also unsexy 
>>>work.
>>
>>How hard is it to look at a web page?
>
>That's not the right question :)
>
>The real questions are: how hard is it to remember how to find the 
>appropriate
>web page

Oh, come on.  I don't believe this.
>how hard is it to know which buildbots are *actually* stable enough
>to rely on,

This is more plausible.  But it's not the tools' fault that the test 
suite has intermittent failures.  Developers choose to add new features 
or change existing ones instead of fixing bugs in existing code or 
tests.  I'd call that a developer failure.
>how hard is it to decipher the results to know what they're
>telling you?

Red bad, green good.

A much more plausible explanation, to me, is that most developers don't 
really care if things are completely working most of the time.  They're 
happy to push the work onto other developers and onto the release team. 
And as long as other developers let them get away with that, it's not 
likely to stop.

But perhaps the people picking up the slack here don't mind and are 
happy to keep doing it, in which case nothing needs to change.

Jean-Paul

From exarkun at twistedmatrix.com  Wed Aug  4 18:45:37 2010
From: exarkun at twistedmatrix.com (exarkun at twistedmatrix.com)
Date: Wed, 04 Aug 2010 16:45:37 -0000
Subject: [Python-Dev] Looking after the buildbots (in general)
In-Reply-To: <i3c2i5$322$1@dough.gmane.org>
References: <i3aeij$146$1@dough.gmane.org> <20100804111613.4e1273f7@pitrou.net>
	<20100804105119.6ae19dc3@heresy>
	<20100804151553.2305.954819342.divmod.xquotient.83@localhost.localdomain>
	<i3c2i5$322$1@dough.gmane.org>
Message-ID: <20100804164537.2305.1371241718.divmod.xquotient.97@localhost.localdomain>

On 03:53 pm, g.brandl at gmx.net wrote:
>Am 04.08.2010 17:15, schrieb exarkun at twistedmatrix.com:
>>On 02:51 pm, barry at python.org wrote:
>>>On Aug 04, 2010, at 11:16 AM, Antoine Pitrou wrote:
>>>>I think the issue is that many core developers don't have the reflex
>>>>to check buildbot state after they commit some changes (or at least
>>>>on a regular, say weekly, basis), and so gradually the buildbots 
>>>>have
>>>>a tendency to turn from green to red, one after another.
>>>
>>>I'd classify this as a failure of the tools, not of the developers.
>>>These
>>>post-commit verification steps should be proactive, and scream really
>>>loud (or
>>>even prevent future commits) until everything is green again.
>>>Buildbots
>>>themselves can be unstable, so this may or may not be workable, and
>>>changing
>>>any of this will take valuable volunteer time.  It's also unsexy 
>>>work.
>>
>>How hard is it to look at a web page?
>
>The hard part is to know *when* to look.  As you might have noticed, 
>the
>Python test suite does not run in ten seconds, especially on some of 
>the
>buildbots -- it can take 1-2 there to complete.  So if you look too 
>soon,
>you won't see all the results, and usually the slow systems are the
>interesting ones.
>
>Now we could of course have a commit hook that counts down two hours 
>and
>then sends an email to the committer "Now look at the buildbot!"...

I don't think it's that hard to take a look at the end of the day (or 
before starting anything else the next morning).  All it really takes is 
a choice on the part of each developer to care whether or not their 
changes are correct.

Jean-Paul

From solipsis at pitrou.net  Wed Aug  4 18:58:09 2010
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 4 Aug 2010 18:58:09 +0200
Subject: [Python-Dev] Looking after the buildbots (in general)
References: <i3aeij$146$1@dough.gmane.org> <20100804111613.4e1273f7@pitrou.net>
	<20100804105119.6ae19dc3@heresy>
	<20100804151553.2305.954819342.divmod.xquotient.83@localhost.localdomain>
	<i3c2i5$322$1@dough.gmane.org>
	<20100804164537.2305.1371241718.divmod.xquotient.97@localhost.localdomain>
Message-ID: <20100804185809.4964a60e@pitrou.net>

On Wed, 04 Aug 2010 16:45:37 -0000
exarkun at twistedmatrix.com wrote:
> 
> I don't think it's that hard to take a look at the end of the day (or 
> before starting anything else the next morning).  All it really takes is 
> a choice on the part of each developer to care whether or not their 
> changes are correct.

And as reported by Ezio, using bbreport makes it extra easy:

$ bbreport.py -q 3.x
Selected builders: 20 / 80 (branch: 3.x)
3.x.dmg                    83717, 83666, 528, 403
ARMv4 Debian 3.x            *** , 83681, 649, 636 # hung for 30 min
ARMv7Thumb Ubuntu 3.x      83025, 82997, 985, 985 # failed slave lost
[etc.]

http://code.google.com/p/bbreport/
hg clone https://bbreport.googlecode.com/hg/ bbreport

Regards

Antoine.



From g.brandl at gmx.net  Wed Aug  4 19:03:20 2010
From: g.brandl at gmx.net (Georg Brandl)
Date: Wed, 04 Aug 2010 19:03:20 +0200
Subject: [Python-Dev] Looking after the buildbots (in general)
In-Reply-To: <AANLkTinkPd2VjA0N3nMbLpO4hVqmpj-Of=F1u_We57j5@mail.gmail.com>
References: <i3aeij$146$1@dough.gmane.org>
	<20100804111613.4e1273f7@pitrou.net>	<20100804105119.6ae19dc3@heresy>	<20100804151553.2305.954819342.divmod.xquotient.83@localhost.localdomain>	<i3c2i5$322$1@dough.gmane.org>
	<AANLkTinkPd2VjA0N3nMbLpO4hVqmpj-Of=F1u_We57j5@mail.gmail.com>
Message-ID: <i3c6lm$jdk$1@dough.gmane.org>

Am 04.08.2010 18:21, schrieb David Stanek:
> On Wed, Aug 4, 2010 at 11:53 AM, Georg Brandl <g.brandl at gmx.net> wrote:
>>
>> The hard part is to know *when* to look.  As you might have noticed, the
>> Python test suite does not run in ten seconds, especially on some of the
>> buildbots -- it can take 1-2 there to complete.  So if you look too soon,
>> you won't see all the results, and usually the slow systems are the
>> interesting ones.
>>
>> Now we could of course have a commit hook that counts down two hours and
>> then sends an email to the committer "Now look at the buildbot!"...
>>
> 
> Why not have buildbot slaves email the committer when their change
> broke the build. I realize that if you break 25 slaves it would not be
> pleasant to receive 25 emails, but I've had worse things happen. Or
> buildbot slaves can report failures to a mailing list or IRC chat.

This is what we did once (or the mails were sent to python-dev, I don't
remember), but it became ugly fast whenever the buildbots became unstable.
Also, some of the buildbot slave owners do not have endless spare time
to look at issues on their side.

Once we manage to get them into a mostly stable situation again, we
should definitely enable notifications in on form or other again.

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.


From g.brandl at gmx.net  Wed Aug  4 19:05:34 2010
From: g.brandl at gmx.net (Georg Brandl)
Date: Wed, 04 Aug 2010 19:05:34 +0200
Subject: [Python-Dev] Looking after the buildbots (in general)
In-Reply-To: <20100804164537.2305.1371241718.divmod.xquotient.97@localhost.localdomain>
References: <i3aeij$146$1@dough.gmane.org>
	<20100804111613.4e1273f7@pitrou.net>	<20100804105119.6ae19dc3@heresy>	<20100804151553.2305.954819342.divmod.xquotient.83@localhost.localdomain>	<i3c2i5$322$1@dough.gmane.org>
	<20100804164537.2305.1371241718.divmod.xquotient.97@localhost.localdomain>
Message-ID: <i3c6pr$jdk$2@dough.gmane.org>

Am 04.08.2010 18:45, schrieb exarkun at twistedmatrix.com:
>>>How hard is it to look at a web page?
>>
>>The hard part is to know *when* to look.  As you might have noticed, 
>>the
>>Python test suite does not run in ten seconds, especially on some of 
>>the
>>buildbots -- it can take 1-2 there to complete.  So if you look too 
>>soon,
>>you won't see all the results, and usually the slow systems are the
>>interesting ones.
>>
>>Now we could of course have a commit hook that counts down two hours 
>>and
>>then sends an email to the committer "Now look at the buildbot!"...
> 
> I don't think it's that hard to take a look at the end of the day (or 
> before starting anything else the next morning).  All it really takes is 
> a choice on the part of each developer to care whether or not their 
> changes are correct.

That's true.  However, when most of the time you're looking at the buildbots
you have to check 10 different red ones, only to realize none of the failures
is related to any recent commit, this gets tiresome fast.

I know that the remedy is to get the buildbots stable, but hey, somebody has
to do that.  It's probably not you, and it's probably not me.

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.


From barry at python.org  Wed Aug  4 19:34:26 2010
From: barry at python.org (Barry Warsaw)
Date: Wed, 4 Aug 2010 13:34:26 -0400
Subject: [Python-Dev] Looking after the buildbots (in general)
In-Reply-To: <20100804185809.4964a60e@pitrou.net>
References: <i3aeij$146$1@dough.gmane.org> <20100804111613.4e1273f7@pitrou.net>
	<20100804105119.6ae19dc3@heresy>
	<20100804151553.2305.954819342.divmod.xquotient.83@localhost.localdomain>
	<i3c2i5$322$1@dough.gmane.org>
	<20100804164537.2305.1371241718.divmod.xquotient.97@localhost.localdomain>
	<20100804185809.4964a60e@pitrou.net>
Message-ID: <20100804133426.0c673119@heresy>

On Aug 04, 2010, at 06:58 PM, Antoine Pitrou wrote:

>On Wed, 04 Aug 2010 16:45:37 -0000
>exarkun at twistedmatrix.com wrote:
>> 
>> I don't think it's that hard to take a look at the end of the day
>> (or before starting anything else the next morning).  All it really
>> takes is a choice on the part of each developer to care whether or
>> not their changes are correct.
>
>And as reported by Ezio, using bbreport makes it extra easy:
>
>$ bbreport.py -q 3.x
>Selected builders: 20 / 80 (branch: 3.x)
>3.x.dmg                    83717, 83666, 528, 403
>ARMv4 Debian 3.x            *** , 83681, 649, 636 # hung for 30 min
>ARMv7Thumb Ubuntu 3.x      83025, 82997, 985, 985 # failed slave lost
>[etc.]
>
>http://code.google.com/p/bbreport/
>hg clone https://bbreport.googlecode.com/hg/ bbreport

It would be kind of nice to integrate this with release.py.

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100804/4a05423c/attachment.pgp>

From martin at v.loewis.de  Wed Aug  4 19:42:31 2010
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 04 Aug 2010 19:42:31 +0200
Subject: [Python-Dev] Windows
In-Reply-To: <AANLkTinJA9Xxvmn42GLhHuKA7MYtWe_vBi5k0_wP6Enz@mail.gmail.com>
References: <i3aeij$146$1@dough.gmane.org> <4C591B79.9020407@timgolden.me.uk>
	<AANLkTinJA9Xxvmn42GLhHuKA7MYtWe_vBi5k0_wP6Enz@mail.gmail.com>
Message-ID: <4C59A687.5080402@v.loewis.de>

> I don't really have any answer to this problem right now. Is it
> possible to set up a local buildslave-like environment (so I can run
> the test suite on my development PC without needing to set up access
> and register that PC as a temporary buildslave, which wouldn't be
> practical for me)? If I can get an environment where I can run the
> tests as I need and debug them in place, I might be able to work on
> improving the reliability of things.

Not sure what you are asking. It's certainly possible to run the test
suite yourself: just invoke "python Lib\test\regrtest.py" or some such.

So I assume you are asking for something else.

Regards,
Martin

From alexander.belopolsky at gmail.com  Wed Aug  4 19:46:52 2010
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Wed, 4 Aug 2010 13:46:52 -0400
Subject: [Python-Dev] Add aware local time support to datetime module
In-Reply-To: <AANLkTinwyUr0cwQJFz-A=ojQcDadCcwLgqLkqhgTA46a@mail.gmail.com>
References: <AANLkTinwyUr0cwQJFz-A=ojQcDadCcwLgqLkqhgTA46a@mail.gmail.com>
Message-ID: <AANLkTinXNr8F6mGb2X8Bbj42Ou1OuUwiAmW+dE9nByYv@mail.gmail.com>

[I've got no response from python-ideas, so I am forwarding to python-dev.]

With addition of fixed offset timezone class and the timezone.utc
instance [0], it is easy to get UTC time as an aware datetime
instance:

>>> datetime.now(timezone.utc)
datetime.datetime(2010, 8, 3, 14, 16, 10, 670308, tzinfo=datetime.timezone.utc)

However, if you want to keep time in your local timezone, getting an
aware datetime is almost a catch 22. ?If you know your timezone UTC
offset, you can do

>>> EDT = timezone(timedelta(hours=-4))
>>> datetime.now(EDT)
datetime.datetime(2010, 8, 3, 10, 20, 23, 769537,
tzinfo=datetime.timezone(datetime.timedelta(-1, 72000)))

but the problem is that there is no obvious or even correct way to
find local timezone UTC offset. [1]

In a comment on issue #5094 ("datetime lacks concrete tzinfo
implementation for UTC"), I proposed to address this problem in a
localtime([t]) function that would return current time (or time
corresponding to the optional datetime argument) as an aware datetime
object carrying local timezone information in a tzinfo set to an
appropriate timezone instance. ? This solution is attractive by its
simplicity, but there are several problems:

1. An aware datetime cannot carry all information that system
localtime() supplies in a time tuple. ?Specifically, the is_dst flag
is lost. ?This is not a problem for most applications as long as
timezone UTC offset and timezone name are available, but may be an
issue when interoperability with the time module is required.

2. ?Datetime's tzinfo interface was designed with the idea that
<2010-11-06 12:00 EDT> + <1 day> = ?<2010-11-07 12:00 EST>, not
<2010-11-07 12:00 EDT>. It other words, if I have lunch with someone
at noon (12:00 EDT) on Saturday the day before first Sunday in
November, and want to meet again "at the same time tomorrow", I mean
12:00 EST, not 24 hours later. ?With localtime() returning datetime
with tzinfo set to fixed offset timezone, however, localtime() ?+
timedelta(1) will mean exactly 24 hours later and the result will be
expressed in an unusual for the given location timezone.

An alternative approach is the one recommended in the python manual.
[3] ?One could implement a LocalTimezone class with utcoffset(),
tzname() and dst() extracting information from system mktime and
localtime calls. ?This approach has its own shortcomings:

1. While adding integral number of days to datetimes in business
setting, it is natural to expect automatic timezone adjustments, it is
not as clearcut when adding hours or minutes.

2. The tzinfo.utcoffset() interface that expects *standard* local time
as an argument is confusing to many users. ?Even the "official"
example in the python manual gets it wrong. [4]

3. datetime(..., tzinfo=LocalTimezone()) is ambiguous during the
"repeated hour" when local clock is set back in DST to standard time
transition.

As far as I can tell, the only way to resolve the last problem is to
add is_dst flag to the datetime object, which would also be the
only way to achieve full interoperability between datetime objects and
time tuples. [5]

The traditional answer to call for improvement of timezone support in
datetime module has been: "this is upto 3rd parties to implement."
Unfortunately, stdlib is asking 3rd parties to implement an impossible
interface without giving access to the necessary data. ? The
impossibility comes from the requirement that dst() method should find
out whether local time represents DST or standard time while there is
an hour each year when the same local time can be either. ?The missing
data is the system UTC offset when it changes historically. ?The time
module only gives access to the current UTC offset.

My preference is to implement the first alternative - localtime([t])
returning aware datetime with fixed offset timezone. ?This will solve
the problem of python's lack of access to the universally available
system facilities that are necessary to implement any kind of aware
local time support.

[0] http://docs.python.org/dev/library/datetime.html#timezone-objects
[1] http://bugs.python.org/issue1647654
[2] http://bugs.python.org/issue5094#msg106997
[3] http://docs.python.org/library/datetime.html#tzinfo-objects
[4] http://bugs.python.org/issue9063
[5] http://bugs.python.org/issue9004

From martin at v.loewis.de  Wed Aug  4 19:49:09 2010
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 04 Aug 2010 19:49:09 +0200
Subject: [Python-Dev] Windows
In-Reply-To: <AANLkTikYTggbsobwSZN+pcX5Wv1AaqFoYccsyQh-Z6YG@mail.gmail.com>
References: <i3aeij$146$1@dough.gmane.org>
	<20100804104810.4197e870@heresy>	<AANLkTimN7uW_ZA-esR5UTv-Pp-342WjzL7OL46pJV1e5@mail.gmail.com>	<4C59898D.9040106@holdenweb.com>
	<4C598C08.3070207@timgolden.me.uk>
	<AANLkTikYTggbsobwSZN+pcX5Wv1AaqFoYccsyQh-Z6YG@mail.gmail.com>
Message-ID: <4C59A815.2060400@v.loewis.de>

> http://docs.pythonsprints.com/core_development/beginners.html
> 
> Building ssl requires Perl and nasm, and gets completed as a post-build
> step. I haven't done that in a while but it's documented in
> PCBuild/readme.txt. That's the stuff I'll be adding to the above document.

Perl shouldn't be a requirement if you use the OpenSSL copy from
svn.python.org.

Regards,
Martin

From martin at v.loewis.de  Wed Aug  4 19:53:55 2010
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Wed, 04 Aug 2010 19:53:55 +0200
Subject: [Python-Dev] [python-committers]  (Windows) buildbots on 3.x
In-Reply-To: <1280936002.3231.4.camel@localhost.localdomain>
References: <AANLkTimK48CRc53_ymurdA+aKo-EDFLM5Nxra5poGWfK@mail.gmail.com>	<AANLkTi=K55K-Bv6wsfUMs5XYMBcdK50biLTgL74ZuiKw@mail.gmail.com>	<1280923543.3231.0.camel@localhost.localdomain>	<AANLkTi=5bxYwuaTDaQ6QXBrxJcW85W+b-nmvqajM3Sor@mail.gmail.com>
	<1280936002.3231.4.camel@localhost.localdomain>
Message-ID: <4C59A933.4070307@v.loewis.de>

>>> It happens when running test_smtplib before test_smtpb:
>>
>> Nice! How did you work that out? I'd like to learn how to diagnose
>> this sort of thing, because it seems to come up a lot, and I'm not
>> much use at the moment :-)
> 
> I simply tried to run test_smtplib before test_smtpd.

A more deterministic (and more tedious) way is this: if you
suspect that some failure might be due to the order of test cases,
take a build log from the build bot where it fails, and run the tests
in the exact same order. See whether the problem reproduces.

If it does, drop tests from the test sequence until you end up with
the minimum number of tests that you need to run in sequence (and yes,
I had interworkings of three test modules at some point).

Of course, educated guessing can accelerate the process.

Regards,
Martin

From steve at holdenweb.com  Wed Aug  4 19:56:27 2010
From: steve at holdenweb.com (Steve Holden)
Date: Wed, 04 Aug 2010 13:56:27 -0400
Subject: [Python-Dev] Looking after the buildbots (in general)
In-Reply-To: <20100804164225.2305.654532857.divmod.xquotient.91@localhost.localdomain>
References: <i3aeij$146$1@dough.gmane.org>
	<20100804111613.4e1273f7@pitrou.net>	<20100804105119.6ae19dc3@heresy>	<20100804151553.2305.954819342.divmod.xquotient.83@localhost.localdomain>	<20100804113140.03aaf80b@heresy>
	<20100804164225.2305.654532857.divmod.xquotient.91@localhost.localdomain>
Message-ID: <i3c9kn$uje$1@dough.gmane.org>

On 8/4/2010 12:42 PM, exarkun at twistedmatrix.com wrote:
> On 03:31 pm, barry at python.org wrote:
>> On Aug 04, 2010, at 03:15 PM, exarkun at twistedmatrix.com wrote:
>>> On 02:51 pm, barry at python.org wrote:
>>>> On Aug 04, 2010, at 11:16 AM, Antoine Pitrou wrote:
>>>>> I think the issue is that many core developers don't have the reflex
>>>>> to check buildbot state after they commit some changes (or at least
>>>>> on a regular, say weekly, basis), and so gradually the buildbots have
>>>>> a tendency to turn from green to red, one after another.
>>>>
>>>> I'd classify this as a failure of the tools, not of the developers.
>>>>> These post-commit verification steps should be proactive, and scream
>>>>> really >loud (or
>>>> even prevent future commits) until everything is green again.
>>>>> Buildbots themselves can be unstable, so this may or may not be
>>>>> workable, and >changing
>>>> any of this will take valuable volunteer time.  It's also unsexy work.
>>>
>>> How hard is it to look at a web page?
>>
>> That's not the right question :)
>>
>> The real questions are: how hard is it to remember how to find the
>> appropriate
>> web page
> 
> Oh, come on.  I don't believe this.
>> how hard is it to know which buildbots are *actually* stable enough
>> to rely on,
> 
> This is more plausible.  But it's not the tools' fault that the test
> suite has intermittent failures.  Developers choose to add new features
> or change existing ones instead of fixing bugs in existing code or
> tests.  I'd call that a developer failure.
>> how hard is it to decipher the results to know what they're
>> telling you?
> 
> Red bad, green good.
> 
> A much more plausible explanation, to me, is that most developers don't
> really care if things are completely working most of the time.  They're
> happy to push the work onto other developers and onto the release team.
> And as long as other developers let them get away with that, it's not
> likely to stop.
> 
> But perhaps the people picking up the slack here don't mind and are
> happy to keep doing it, in which case nothing needs to change.

This whole discussion seems to make it clear that the release manager
procedures are still ill-defined in certain areas. Otherwise a release
manager could proceed by reading a web page an even, heaven help us,
following specific links to ensure particular actions were taken.

But I see rules being established ("there's a language moratorium: no
changes!", "no release should be made unless the buildbots are *all*
green") and then ignored apparently on a whim. This doesn't give people
any confidence that the rules actually mean much, and I think ignoring
the latter rule can negatively affect quality.

Establishing comprehensive procedures can be as difficult as
programming, though, and requires skills that have eluded me through a
fairly lengthy technical career. So it also boils down to shortage of
manpower of a particular kind. People with programming skill would,
understandably, rather invest their time in something they are good at.

regards
 Steve


-- 
Steve Holden           +1 571 484 6266   +1 800 494 3119
DjangoCon US September 7-9, 2010    http://djangocon.us/
See Python Video!       http://python.mirocommunity.org/
Holden Web LLC                 http://www.holdenweb.com/


From fuzzyman at voidspace.org.uk  Wed Aug  4 20:02:34 2010
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Wed, 04 Aug 2010 19:02:34 +0100
Subject: [Python-Dev] [python-committers]  (Windows) buildbots on 3.x
In-Reply-To: <4C59A933.4070307@v.loewis.de>
References: <AANLkTimK48CRc53_ymurdA+aKo-EDFLM5Nxra5poGWfK@mail.gmail.com>	<AANLkTi=K55K-Bv6wsfUMs5XYMBcdK50biLTgL74ZuiKw@mail.gmail.com>	<1280923543.3231.0.camel@localhost.localdomain>	<AANLkTi=5bxYwuaTDaQ6QXBrxJcW85W+b-nmvqajM3Sor@mail.gmail.com>	<1280936002.3231.4.camel@localhost.localdomain>
	<4C59A933.4070307@v.loewis.de>
Message-ID: <4C59AB3A.1050601@voidspace.org.uk>

On 04/08/2010 18:53, "Martin v. L?wis" wrote:
>>>> It happens when running test_smtplib before test_smtpb:
>>>>          
>>> Nice! How did you work that out? I'd like to learn how to diagnose
>>> this sort of thing, because it seems to come up a lot, and I'm not
>>> much use at the moment :-)
>>>        
>> I simply tried to run test_smtplib before test_smtpd.
>>      
> A more deterministic (and more tedious) way is this: if you
> suspect that some failure might be due to the order of test cases,
> take a build log from the build bot where it fails, and run the tests
> in the exact same order. See whether the problem reproduces.
>
> If it does, drop tests from the test sequence until you end up with
> the minimum number of tests that you need to run in sequence (and yes,
> I had interworkings of three test modules at some point).
>
>    

A colleague in a previous job wrote a tool that would repeat a test 
sequence using a binary chop to find test interactions... It could take 
a while to run, but was usually faster than manually trying to find them 
(assuming educated guessing had already failed).

Michael

> Of course, educated guessing can accelerate the process.
>
> Regards,
> Martin
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at 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/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (?BOGUS AGREEMENTS?) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.



From lukasz at langa.pl  Wed Aug  4 20:05:09 2010
From: lukasz at langa.pl (=?utf-8?Q?=C5=81ukasz_Langa?=)
Date: Wed, 4 Aug 2010 20:05:09 +0200
Subject: [Python-Dev] Looking after the buildbots (in general)
In-Reply-To: <i3c9kn$uje$1@dough.gmane.org>
References: <i3aeij$146$1@dough.gmane.org>
	<20100804111613.4e1273f7@pitrou.net>	<20100804105119.6ae19dc3@heresy>	<20100804151553.2305.954819342.divmod.xquotient.83@localhost.localdomain>	<20100804113140.03aaf80b@heresy>
	<20100804164225.2305.654532857.divmod.xquotient.91@localhost.localdomain>
	<i3c9kn$uje$1@dough.gmane.org>
Message-ID: <F3085BE2-4C8A-4462-987B-F80D0C985728@langa.pl>


Wiadomo?? napisana przez Steve Holden w dniu 2010-08-04, o godz. 19:56:

> But I see rules being established ("there's a language moratorium: no
> changes!", "no release should be made unless the buildbots are *all*
> green") and then ignored apparently on a whim. This doesn't give people
> any confidence that the rules actually mean much

Very good point.

-- 
Best regards,
?ukasz Langa
tel. +48 791 080 144
WWW http://lukasz.langa.pl/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100804/a9327330/attachment.html>

From solipsis at pitrou.net  Wed Aug  4 20:21:10 2010
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 4 Aug 2010 20:21:10 +0200
Subject: [Python-Dev] Looking after the buildbots (in general)
References: <i3aeij$146$1@dough.gmane.org> <20100804111613.4e1273f7@pitrou.net>
	<20100804105119.6ae19dc3@heresy>
	<20100804151553.2305.954819342.divmod.xquotient.83@localhost.localdomain>
	<20100804113140.03aaf80b@heresy>
	<20100804164225.2305.654532857.divmod.xquotient.91@localhost.localdomain>
	<i3c9kn$uje$1@dough.gmane.org>
Message-ID: <20100804202110.5daa5c2f@pitrou.net>

On Wed, 04 Aug 2010 13:56:27 -0400
Steve Holden <steve at holdenweb.com> wrote:
> 
> This whole discussion seems to make it clear that the release manager
> procedures are still ill-defined in certain areas. Otherwise a release
> manager could proceed by reading a web page an even, heaven help us,
> following specific links to ensure particular actions were taken.

This isn't about release management. If we care about buildbots only
the few days before a release, we are doomed.

> Establishing comprehensive procedures can be as difficult as
> programming, though, and requires skills that have eluded me through a
> fairly lengthy technical career. So it also boils down to shortage of
> manpower of a particular kind.

The problem is more of gathering support for a particular policy or
procedure, giving that it isn't necessarily part of the established
culture. There are certainly some of us who do care about buildbot
stability and general test suite quality (a few months ago, we had a
majority of green buildbots, quite consistently; but keeping those
buildbots green in the face of daily SVN activity is an uphill battle
if we don't get support from the majority of committers).

Regards

Antoine.



From barry at python.org  Wed Aug  4 20:25:19 2010
From: barry at python.org (Barry Warsaw)
Date: Wed, 4 Aug 2010 14:25:19 -0400
Subject: [Python-Dev] Looking after the buildbots (in general)
In-Reply-To: <i3c9kn$uje$1@dough.gmane.org>
References: <i3aeij$146$1@dough.gmane.org> <20100804111613.4e1273f7@pitrou.net>
	<20100804105119.6ae19dc3@heresy>
	<20100804151553.2305.954819342.divmod.xquotient.83@localhost.localdomain>
	<20100804113140.03aaf80b@heresy>
	<20100804164225.2305.654532857.divmod.xquotient.91@localhost.localdomain>
	<i3c9kn$uje$1@dough.gmane.org>
Message-ID: <20100804142519.7cae78e4@heresy>

On Aug 04, 2010, at 01:56 PM, Steve Holden wrote:

>But I see rules being established ("there's a language moratorium: no
>changes!", "no release should be made unless the buildbots are *all*
>green") and then ignored apparently on a whim. This doesn't give people
>any confidence that the rules actually mean much, and I think ignoring
>the latter rule can negatively affect quality.

I don't believe we've ever had a rule (as embodied in PEP 101) that a release
requires all buildbots to be green.  I think that would be unachievable due in
large part to the buildbot infrastructure itself not being very stable.  We
have identified some buildbots as "stable" ones and PEP 101 says:

  ___ Check the stable buildbots.

      Go to http://www.python.org/dev/buildbot/stable/

      (the trailing slash is required).  Look at the buildbots for the release
      you're making.  Ignore any that are offline (or inform the community so
      they can be restarted).  If what remains are (mostly) green buildbots,
      you're good to go.  If you have non-offline red buildbots, you may want
      to hold up the release until they are fixed.  Review the problems and
      use your judgement, taking into account whether you are making an alpha,
      beta, or final release.

Even having non-offline stable buildbots completely green for a release would
take work we don't have the manpower for.  When I'm doing a release, I
certainly consult both the stable and unstable buildbots, but I always run the
full test suite on local platforms I have access too, which covers Linux, OS
X, and hopefully soon Windows.  #python-dev is helpful here for providing some
additional sanity checks.

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100804/47a6ba14/attachment.pgp>

From tjreedy at udel.edu  Wed Aug  4 20:50:22 2010
From: tjreedy at udel.edu (Terry Reedy)
Date: Wed, 04 Aug 2010 14:50:22 -0400
Subject: [Python-Dev] question
In-Reply-To: <AANLkTinaGEY6OpkKCUW5z+Fuxx2Gsm6sE44QEJ06zyOq@mail.gmail.com>
References: <770261.21244.qm@web65811.mail.ac4.yahoo.com>
	<AANLkTinaGEY6OpkKCUW5z+Fuxx2Gsm6sE44QEJ06zyOq@mail.gmail.com>
Message-ID: <i3ccpa$a2g$1@dough.gmane.org>

On 8/4/2010 3:08 AM, Senthil Kumaran wrote:
> Hello,
>
> Please ask the support questions at:
>
> http://groups.google.com/group/comp.lang.python

Some people filter out posts from google because of spam.
Better gmane.comp.python.general at news.gmane.org
or python-list at python.org.

-- 
Terry Jan Reedy


From martin at v.loewis.de  Wed Aug  4 20:57:48 2010
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 04 Aug 2010 20:57:48 +0200
Subject: [Python-Dev] Looking after the buildbots (in general)
In-Reply-To: <i3c9kn$uje$1@dough.gmane.org>
References: <i3aeij$146$1@dough.gmane.org>	<20100804111613.4e1273f7@pitrou.net>	<20100804105119.6ae19dc3@heresy>	<20100804151553.2305.954819342.divmod.xquotient.83@localhost.localdomain>	<20100804113140.03aaf80b@heresy>	<20100804164225.2305.654532857.divmod.xquotient.91@localhost.localdomain>
	<i3c9kn$uje$1@dough.gmane.org>
Message-ID: <4C59B82C.8040501@v.loewis.de>

> This whole discussion seems to make it clear that the release manager
> procedures are still ill-defined in certain areas.

No. It rather makes clear that people who never had the role of release
manager

> Otherwise a release
> manager could proceed by reading a web page an even, heaven help us,
> following specific links to ensure particular actions were taken.

When Barry had the keys to the time machine, he wrote PEP 101,
to give you a web page with specific links in it:

http://www.python.org/dev/peps/pep-0101/

> But I see rules being established ("there's a language moratorium: no
> changes!", "no release should be made unless the buildbots are *all*
> green") and then ignored apparently on a whim.

What makes you say that?

> Establishing comprehensive procedures can be as difficult as
> programming, though, and requires skills that have eluded me through a
> fairly lengthy technical career. So it also boils down to shortage of
> manpower of a particular kind. People with programming skill would,
> understandably, rather invest their time in something they are good at.

I think you are belittling the contributions of past and present
release managers.

Regards,
Martin

From p.f.moore at gmail.com  Wed Aug  4 21:03:14 2010
From: p.f.moore at gmail.com (Paul Moore)
Date: Wed, 4 Aug 2010 20:03:14 +0100
Subject: [Python-Dev] Windows
In-Reply-To: <4C59A687.5080402@v.loewis.de>
References: <i3aeij$146$1@dough.gmane.org> <4C591B79.9020407@timgolden.me.uk>
	<AANLkTinJA9Xxvmn42GLhHuKA7MYtWe_vBi5k0_wP6Enz@mail.gmail.com>
	<4C59A687.5080402@v.loewis.de>
Message-ID: <AANLkTi=n+1RZ3Z4Msrrg86JrWBPni1ruNmaZAf9MFJ8+@mail.gmail.com>

On 4 August 2010 18:42, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>> I don't really have any answer to this problem right now. Is it
>> possible to set up a local buildslave-like environment (so I can run
>> the test suite on my development PC without needing to set up access
>> and register that PC as a temporary buildslave, which wouldn't be
>> practical for me)? If I can get an environment where I can run the
>> tests as I need and debug them in place, I might be able to work on
>> improving the reliability of things.
>
> Not sure what you are asking. It's certainly possible to run the test
> suite yourself: just invoke "python Lib\test\regrtest.py" or some such.
>
> So I assume you are asking for something else.

Sorry, I wasn't clear. The issues I see tend to look like they come
from the test suite being run under the control of the buildbot
service - issues caused by not having a terminal session or window
station (like the JIT debugger appearing, which Curt pointed out a way
of addressing) or issues relating to my seeing orphaned python_d.exe
processes which never occur for me when running the test suite
manually.

I'm guessing that these issues aren't "simple" test failures, but
somehow triggered by the way in which the environment buildbot
provides differs from a "normal" console session, and so I was looking
for a way to reproduce those conditions.

Paul.

From p.f.moore at gmail.com  Wed Aug  4 21:17:23 2010
From: p.f.moore at gmail.com (Paul Moore)
Date: Wed, 4 Aug 2010 20:17:23 +0100
Subject: [Python-Dev] Windows
In-Reply-To: <20100804104810.4197e870@heresy>
References: <i3aeij$146$1@dough.gmane.org>
	<20100804104810.4197e870@heresy>
Message-ID: <AANLkTi=Qf5aSyLDh7VLG9k8+vWLj=BkKKd8nDkfEXYWz@mail.gmail.com>

On 4 August 2010 15:48, Barry Warsaw <barry at python.org> wrote:
> Should note that I did try to build Python using my MSDN license for Windows 7
> and Visual Studio 2010. ?I only had an hour or so to attempt it, and did not
> succeed, though I think I got as far as trying to properly situate various
> dependent libraries (sqlite, ssl).
>
> If anybody's successfully navigated the twisty maze, would you be able to
> write something up on the wiki to describe the steps you've taken?

I could probably reasonably easily set up a (VMWare/VirtualBox) VM
image of a Windows 7 system with VS installed and all the
infrastructure set up for Python development/testing, using my MSDN
license (in fact, that's something I keep meaning to do for my own
purposes, anyway).

I don't know what issues there might be in making that available for
others to use - on the one hand, it would need to be protected so that
it couldn't be taken by just anyone, and it may be necessary to set
something up to allow other users to re-register the software with
their own license keys, but in principle that's just "a matter of
programming"...

Hosting might also be fun - I'm on an ADSL connection so uploading a
(multi-)gigabyte image could be a challenge :-)

If there's interest in this (and more particularly, if anyone could
offer advice on what would be needed to be sure I do it legally!), let
me know and I'll look into it.
Paul.

From martin at v.loewis.de  Wed Aug  4 21:17:38 2010
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 04 Aug 2010 21:17:38 +0200
Subject: [Python-Dev] Windows
In-Reply-To: <AANLkTi=n+1RZ3Z4Msrrg86JrWBPni1ruNmaZAf9MFJ8+@mail.gmail.com>
References: <i3aeij$146$1@dough.gmane.org>	<4C591B79.9020407@timgolden.me.uk>	<AANLkTinJA9Xxvmn42GLhHuKA7MYtWe_vBi5k0_wP6Enz@mail.gmail.com>	<4C59A687.5080402@v.loewis.de>
	<AANLkTi=n+1RZ3Z4Msrrg86JrWBPni1ruNmaZAf9MFJ8+@mail.gmail.com>
Message-ID: <4C59BCD2.7030204@v.loewis.de>

Am 04.08.2010 21:03, schrieb Paul Moore:
> On 4 August 2010 18:42, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>>> I don't really have any answer to this problem right now. Is it
>>> possible to set up a local buildslave-like environment (so I can run
>>> the test suite on my development PC without needing to set up access
>>> and register that PC as a temporary buildslave, which wouldn't be
>>> practical for me)? If I can get an environment where I can run the
>>> tests as I need and debug them in place, I might be able to work on
>>> improving the reliability of things.
> 
> Sorry, I wasn't clear. The issues I see tend to look like they come
> from the test suite being run under the control of the buildbot
> service - issues caused by not having a terminal session or window
> station (like the JIT debugger appearing, which Curt pointed out a way
> of addressing) or issues relating to my seeing orphaned python_d.exe
> processes which never occur for me when running the test suite
> manually.

Ah. It should certainly be possible to set this up locally - you just
need to run a buildbot master as well, either on the same machine
or a different one. The only thing you can't then get is automatic
notifications on commits. You could emulate this with manually
triggering builds over the master web pages, or by using buildbot's
svnpoller change source (which defaults to a poll interval of 10min).

To get started, I could share with you the master configuration of
python.org (with account information stripped, of course).

Regards,
Martin



From nas at arctrix.com  Wed Aug  4 21:48:02 2010
From: nas at arctrix.com (Neil Schemenauer)
Date: Wed, 4 Aug 2010 19:48:02 +0000 (UTC)
Subject: [Python-Dev] Looking after the buildbots (in general)
References: <i3aeij$146$1@dough.gmane.org>
	<20100804111613.4e1273f7@pitrou.net> <20100804105119.6ae19dc3@heresy>
	<20100804151553.2305.954819342.divmod.xquotient.83@localhost.localdomain>
	<i3c2i5$322$1@dough.gmane.org>
Message-ID: <i3cg5i$oaj$1@dough.gmane.org>

Georg Brandl <g.brandl at gmx.net> wrote:
> The hard part is to know *when* to look.  As you might have noticed, the
> Python test suite does not run in ten seconds, especially on some of the
> buildbots -- it can take 1-2 there to complete.

Based on this and other issues, I don't think it's practical to
expect that people will always check that their commits pass tests
on all platforms.

Perhaps a slight change in culture is necessary.  When someone finds
a problem with a buildbot, the first response is should be to
request that the committer attempt to fix the problem.  Finding the
guilty party can be easier said than done since there could be
multiple problems or if the problem has been present for a long
time.  Another complication is that the commiter may not have access
to the plaform and require it for debugging purposes.

Basically, I think better communication could mostly solve the
problem.  If someone finds a test failing on a certain plaform, it's
okay to complain about it.   You don't have to fix it yourself.
Perhaps the simpliest approach would be to open a new issue.

  Neil


From steve at holdenweb.com  Wed Aug  4 21:55:30 2010
From: steve at holdenweb.com (Steve Holden)
Date: Wed, 04 Aug 2010 15:55:30 -0400
Subject: [Python-Dev] Looking after the buildbots (in general)
In-Reply-To: <4C59B82C.8040501@v.loewis.de>
References: <i3aeij$146$1@dough.gmane.org>	<20100804111613.4e1273f7@pitrou.net>	<20100804105119.6ae19dc3@heresy>	<20100804151553.2305.954819342.divmod.xquotient.83@localhost.localdomain>	<20100804113140.03aaf80b@heresy>	<20100804164225.2305.654532857.divmod.xquotient.91@localhost.localdomain>	<i3c9kn$uje$1@dough.gmane.org>
	<4C59B82C.8040501@v.loewis.de>
Message-ID: <i3cgk0$p9r$1@dough.gmane.org>

On 8/4/2010 2:57 PM, "Martin v. L?wis" wrote:
>> This whole discussion seems to make it clear that the release manager
>> procedures are still ill-defined in certain areas.
> 
> No. It rather makes clear that people who never had the role of release
> manager
> 
>> Otherwise a release
>> manager could proceed by reading a web page an even, heaven help us,
>> following specific links to ensure particular actions were taken.
> 
> When Barry had the keys to the time machine, he wrote PEP 101,
> to give you a web page with specific links in it:
> 
> http://www.python.org/dev/peps/pep-0101/
> 
>> But I see rules being established ("there's a language moratorium: no
>> changes!", "no release should be made unless the buildbots are *all*
>> green") and then ignored apparently on a whim.
> 
> What makes you say that?
> 
>> Establishing comprehensive procedures can be as difficult as
>> programming, though, and requires skills that have eluded me through a
>> fairly lengthy technical career. So it also boils down to shortage of
>> manpower of a particular kind. People with programming skill would,
>> understandably, rather invest their time in something they are good at.
> 
> I think you are belittling the contributions of past and present
> release managers.
> 
I'd prefer to say I was displaying my ignorance.

regards
 Steve
-- 
Steve Holden           +1 571 484 6266   +1 800 494 3119
DjangoCon US September 7-9, 2010    http://djangocon.us/
See Python Video!       http://python.mirocommunity.org/
Holden Web LLC                 http://www.holdenweb.com/


From p.f.moore at gmail.com  Wed Aug  4 21:56:54 2010
From: p.f.moore at gmail.com (Paul Moore)
Date: Wed, 4 Aug 2010 20:56:54 +0100
Subject: [Python-Dev] Windows
In-Reply-To: <4C59BCD2.7030204@v.loewis.de>
References: <i3aeij$146$1@dough.gmane.org> <4C591B79.9020407@timgolden.me.uk>
	<AANLkTinJA9Xxvmn42GLhHuKA7MYtWe_vBi5k0_wP6Enz@mail.gmail.com>
	<4C59A687.5080402@v.loewis.de>
	<AANLkTi=n+1RZ3Z4Msrrg86JrWBPni1ruNmaZAf9MFJ8+@mail.gmail.com>
	<4C59BCD2.7030204@v.loewis.de>
Message-ID: <AANLkTimYsq6d-X9c9XLY-SXW34Rf+rPuhwu+YQewZzrF@mail.gmail.com>

On 4 August 2010 20:17, "Martin v. L?wis" <martin at v.loewis.de> wrote:

> Ah. It should certainly be possible to set this up locally - you just
> need to run a buildbot master as well, either on the same machine
> or a different one. The only thing you can't then get is automatic
> notifications on commits. You could emulate this with manually
> triggering builds over the master web pages, or by using buildbot's
> svnpoller change source (which defaults to a poll interval of 10min).
>
> To get started, I could share with you the master configuration of
> python.org (with account information stripped, of course).

Thanks, I'll have a look at what I need to set up when I next get some
time (which may be a few weeks, as I'm on holiday soon :-)). When I
get to a suitable point, I'll get back to you.

It may be that setting up a full master/slave setup is more effort
than it's going to be worth to me (after all, I have a buildslave to
work on in any case...) - I was thinking more of something a little
simpler, just a means of running the tests manually in a service-type
environment. If the buildmaster/slave setup is more than I feel like
setting up, I'll look into that as an alternative.

Thanks for the suggestion.
Paul.

From g.brandl at gmx.net  Wed Aug  4 23:53:22 2010
From: g.brandl at gmx.net (Georg Brandl)
Date: Wed, 04 Aug 2010 23:53:22 +0200
Subject: [Python-Dev] Looking after the buildbots (in general)
In-Reply-To: <i3c2i5$322$1@dough.gmane.org>
References: <i3aeij$146$1@dough.gmane.org>	<20100804111613.4e1273f7@pitrou.net>	<20100804105119.6ae19dc3@heresy>	<20100804151553.2305.954819342.divmod.xquotient.83@localhost.localdomain>
	<i3c2i5$322$1@dough.gmane.org>
Message-ID: <i3cnlf$kk7$1@dough.gmane.org>

Am 04.08.2010 17:53, schrieb Georg Brandl:
> Am 04.08.2010 17:15, schrieb exarkun at twistedmatrix.com:
>> On 02:51 pm, barry at python.org wrote:
>>>On Aug 04, 2010, at 11:16 AM, Antoine Pitrou wrote:
>>>>I think the issue is that many core developers don't have the reflex
>>>>to check buildbot state after they commit some changes (or at least
>>>>on a regular, say weekly, basis), and so gradually the buildbots have
>>>>a tendency to turn from green to red, one after another.
>>>
>>>I'd classify this as a failure of the tools, not of the developers. 
>>>These
>>>post-commit verification steps should be proactive, and scream really 
>>>loud (or
>>>even prevent future commits) until everything is green again. 
>>>Buildbots
>>>themselves can be unstable, so this may or may not be workable, and 
>>>changing
>>>any of this will take valuable volunteer time.  It's also unsexy work.
>> 
>> How hard is it to look at a web page?
> 
> The hard part is to know *when* to look.  As you might have noticed, the
> Python test suite does not run in ten seconds, especially on some of the
> buildbots -- it can take 1-2 there to complete.

That should be "1-2 hours", by the way...

Georg


-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.


From ncoghlan at gmail.com  Wed Aug  4 23:57:07 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 5 Aug 2010 07:57:07 +1000
Subject: [Python-Dev] #2651 - KeyError does not round trip strings
In-Reply-To: <AANLkTikEA9v2fNo_1HHH162C391bNM9DpoPnJzEj1Dy9@mail.gmail.com>
References: <96448358-C3F6-4012-94FC-CAAE8D0F18D9@langa.pl>
	<AANLkTikEA9v2fNo_1HHH162C391bNM9DpoPnJzEj1Dy9@mail.gmail.com>
Message-ID: <AANLkTi=72-K=me-xr+U3_KxVE_sS4yNDfwCibmBpOOPA@mail.gmail.com>

2010/8/5 Fred Drake <fdrake at acm.org>:
> 2010/8/4 ?ukasz Langa <lukasz at langa.pl>:
>> 1. The patch makes KeyError behave analogically to IOError so that the first
>> arg is now a message and the second is the actual key.
>
> I agree with Antoine; there's no point to this.
>
>> 2. Some people suggest adding e.key to KeyError. I like the idea but in my
>> opinion currently it is not implementable in a reliable way.
>
> This is interesting and useful.
>
> I'd be really happy to see e.key be present if the key is known
> (because it was specifically provided to the constructor:
> KeyError(key=...)), or not present if the key isn't known. ?(The idea
> is much less interesting if code can't distinguish between the
> key-is-known and the key-not-known cases.)
>
> The runtime and standard library should be adjusted to provide the key
> whenever possible, of course.
>
> Though I doubt this would break anything, we've lived without this
> long enough that the it doesn't represent a sufficient failing that
> the moratorium should be broken. ?It can wait.

+1 on what Fred said (i.e. post-moratorium, add a keyword-only "key"
argument to KeyError, set "e.key" only if that argument is supplied,
update the standard library to supply it and use a default message of
"'Key not found: %r' % key" if the key argument is supplied without an
explicit message). Also +1 for doing the equivalent with
AttributeError and an "attr" keyword only argument.

Since a keyword-only approach doesn't actually *break* any current
code, I'm only -0 on doing that for 3.2 rather than -1.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From solipsis at pitrou.net  Thu Aug  5 00:02:06 2010
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Thu, 5 Aug 2010 00:02:06 +0200
Subject: [Python-Dev] Looking after the buildbots (in general)
References: <i3aeij$146$1@dough.gmane.org> <20100804111613.4e1273f7@pitrou.net>
	<20100804105119.6ae19dc3@heresy>
	<20100804151553.2305.954819342.divmod.xquotient.83@localhost.localdomain>
	<i3c2i5$322$1@dough.gmane.org> <i3cnlf$kk7$1@dough.gmane.org>
Message-ID: <20100805000206.3e2782cd@pitrou.net>

On Wed, 04 Aug 2010 23:53:22 +0200
Georg Brandl <g.brandl at gmx.net> wrote:
> > 
> > The hard part is to know *when* to look.  As you might have noticed, the
> > Python test suite does not run in ten seconds, especially on some of the
> > buildbots -- it can take 1-2 there to complete.
> 
> That should be "1-2 hours", by the way...

But if the buildbot is late, it can sometimes be 1-2 days.

Antoine.



From fdrake at acm.org  Thu Aug  5 00:02:39 2010
From: fdrake at acm.org (Fred Drake)
Date: Wed, 4 Aug 2010 18:02:39 -0400
Subject: [Python-Dev] #2651 - KeyError does not round trip strings
In-Reply-To: <AANLkTi=72-K=me-xr+U3_KxVE_sS4yNDfwCibmBpOOPA@mail.gmail.com>
References: <96448358-C3F6-4012-94FC-CAAE8D0F18D9@langa.pl> 
	<AANLkTikEA9v2fNo_1HHH162C391bNM9DpoPnJzEj1Dy9@mail.gmail.com> 
	<AANLkTi=72-K=me-xr+U3_KxVE_sS4yNDfwCibmBpOOPA@mail.gmail.com>
Message-ID: <AANLkTi=dD5yqPjs7potXNXCteD5U4Mo1FVwGAdoZFhCY@mail.gmail.com>

On Wed, Aug 4, 2010 at 5:57 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> and use a default message of
> "'Key not found: %r' % key" if the key argument is supplied without an
> explicit message

I suspect you meant a default message of

    'Key not found: %r' % (key,)

since `key` might be a 1-tuple.  :-)


? -Fred

--
Fred L. Drake, Jr.? ? <fdrake at gmail.com>
"A storm broke loose in my mind."? --Albert Einstein

From ncoghlan at gmail.com  Thu Aug  5 00:09:07 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 5 Aug 2010 08:09:07 +1000
Subject: [Python-Dev] #2651 - KeyError does not round trip strings
In-Reply-To: <AANLkTi=dD5yqPjs7potXNXCteD5U4Mo1FVwGAdoZFhCY@mail.gmail.com>
References: <96448358-C3F6-4012-94FC-CAAE8D0F18D9@langa.pl>
	<AANLkTikEA9v2fNo_1HHH162C391bNM9DpoPnJzEj1Dy9@mail.gmail.com>
	<AANLkTi=72-K=me-xr+U3_KxVE_sS4yNDfwCibmBpOOPA@mail.gmail.com>
	<AANLkTi=dD5yqPjs7potXNXCteD5U4Mo1FVwGAdoZFhCY@mail.gmail.com>
Message-ID: <AANLkTinE3UjLUZEYqMmkwnktwmY8HfRY2nyLYAWVQnh3@mail.gmail.com>

On Thu, Aug 5, 2010 at 8:02 AM, Fred Drake <fdrake at acm.org> wrote:
> On Wed, Aug 4, 2010 at 5:57 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> and use a default message of
>> "'Key not found: %r' % key" if the key argument is supplied without an
>> explicit message
>
> I suspect you meant a default message of
>
> ? ?'Key not found: %r' % (key,)
>
> since `key` might be a 1-tuple. ?:-)

Gah, you're right.

Maybe I should have said "'Key not found: {}'.format(key)" :)

Crazy-overloaded-mod-operators'ly,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From g.brandl at gmx.net  Thu Aug  5 00:07:41 2010
From: g.brandl at gmx.net (Georg Brandl)
Date: Thu, 05 Aug 2010 00:07:41 +0200
Subject: [Python-Dev] Looking after the buildbots (in general)
In-Reply-To: <20100804142519.7cae78e4@heresy>
References: <i3aeij$146$1@dough.gmane.org>
	<20100804111613.4e1273f7@pitrou.net>	<20100804105119.6ae19dc3@heresy>	<20100804151553.2305.954819342.divmod.xquotient.83@localhost.localdomain>	<20100804113140.03aaf80b@heresy>	<20100804164225.2305.654532857.divmod.xquotient.91@localhost.localdomain>	<i3c9kn$uje$1@dough.gmane.org>
	<20100804142519.7cae78e4@heresy>
Message-ID: <i3cogh$occ$1@dough.gmane.org>

Am 04.08.2010 20:25, schrieb Barry Warsaw:
> On Aug 04, 2010, at 01:56 PM, Steve Holden wrote:
> 
>>But I see rules being established ("there's a language moratorium: no
>>changes!", "no release should be made unless the buildbots are *all*
>>green") and then ignored apparently on a whim. This doesn't give people
>>any confidence that the rules actually mean much, and I think ignoring
>>the latter rule can negatively affect quality.
> 
> I don't believe we've ever had a rule (as embodied in PEP 101) that a release
> requires all buildbots to be green.  I think that would be unachievable due in
> large part to the buildbot infrastructure itself not being very stable.  We
> have identified some buildbots as "stable" ones and PEP 101 says:

...

> Even having non-offline stable buildbots completely green for a release would
> take work we don't have the manpower for.  When I'm doing a release, I
> certainly consult both the stable and unstable buildbots, but I always run the
> full test suite on local platforms I have access too, which covers Linux, OS
> X, and hopefully soon Windows.  #python-dev is helpful here for providing some
> additional sanity checks.

Same here.  For 3.2a1, I looked at the stable buildbots -- unfortunately, three
out of six were offline.  Of the other three, I fixed a few real bugs, and in
the end two of them were green.  The last one, a Windows 7 machine, had some
obscure failures building OpenSSL, about which I consulted Martin and David,
the owner, and some real issues with the new OpenSSL version were fixed, but
in the end it was still red.

So, I think in the end having the buildbots was a success, even if only 2/6
were green :)

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.


From g.brandl at gmx.net  Thu Aug  5 00:11:51 2010
From: g.brandl at gmx.net (Georg Brandl)
Date: Thu, 05 Aug 2010 00:11:51 +0200
Subject: [Python-Dev] Looking after the buildbots (in general)
In-Reply-To: <i3c9kn$uje$1@dough.gmane.org>
References: <i3aeij$146$1@dough.gmane.org>	<20100804111613.4e1273f7@pitrou.net>	<20100804105119.6ae19dc3@heresy>	<20100804151553.2305.954819342.divmod.xquotient.83@localhost.localdomain>	<20100804113140.03aaf80b@heresy>	<20100804164225.2305.654532857.divmod.xquotient.91@localhost.localdomain>
	<i3c9kn$uje$1@dough.gmane.org>
Message-ID: <i3cooc$p7b$1@dough.gmane.org>

Am 04.08.2010 19:56, schrieb Steve Holden:

> This whole discussion seems to make it clear that the release manager
> procedures are still ill-defined in certain areas.

If you mean to imply that a release manager should care for the stability
of "their" branch also in between of releases -- I'd love to do that,
but I'd need a 36-hour day then.

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.


From lukasz at langa.pl  Thu Aug  5 00:18:10 2010
From: lukasz at langa.pl (=?utf-8?Q?=C5=81ukasz_Langa?=)
Date: Thu, 5 Aug 2010 00:18:10 +0200
Subject: [Python-Dev] #2651 - KeyError does not round trip strings
In-Reply-To: <AANLkTi=72-K=me-xr+U3_KxVE_sS4yNDfwCibmBpOOPA@mail.gmail.com>
References: <96448358-C3F6-4012-94FC-CAAE8D0F18D9@langa.pl>
	<AANLkTikEA9v2fNo_1HHH162C391bNM9DpoPnJzEj1Dy9@mail.gmail.com>
	<AANLkTi=72-K=me-xr+U3_KxVE_sS4yNDfwCibmBpOOPA@mail.gmail.com>
Message-ID: <248F23EA-BACA-4936-8D04-F4BBDF930CE9@langa.pl>


Wiadomo?? napisana przez Nick Coghlan w dniu 2010-08-04, o godz. 23:57:

> 2010/8/5 Fred Drake <fdrake at acm.org>:
>> 2010/8/4 ?ukasz Langa <lukasz at langa.pl>:
>>> 1. The patch makes KeyError behave analogically to IOError so that the first
>>> arg is now a message and the second is the actual key.
>> 
>> I agree with Antoine; there's no point to this.

So I'm proposing to close the original issue #2651 and not include what's there.
(see below though)

>> 
>>> 2. Some people suggest adding e.key to KeyError. I like the idea but in my
>>> opinion currently it is not implementable in a reliable way.
>> 
>> This is interesting and useful.
>> 
>> I'd be really happy to see e.key be present if the key is known
>> (because it was specifically provided to the constructor:
>> KeyError(key=...)), or not present if the key isn't known.  (The idea
>> is much less interesting if code can't distinguish between the
>> key-is-known and the key-not-known cases.)
>> 
>> The runtime and standard library should be adjusted to provide the key
>> whenever possible, of course.
>> 
>> Though I doubt this would break anything, we've lived without this
>> long enough that the it doesn't represent a sufficient failing that
>> the moratorium should be broken.  It can wait.
> 
> +1 on what Fred said (i.e. post-moratorium, add a keyword-only "key"
> argument to KeyError, set "e.key" only if that argument is supplied,
> update the standard library to supply it and use a default message of
> "'Key not found: %r' % key" if the key argument is supplied without an
> explicit message). Also +1 for doing the equivalent with
> AttributeError and an "attr" keyword only argument.

Good stuff guys. Shall we do an e.index for IndexErrors as well?

> Since a keyword-only approach doesn't actually *break* any current
> code, I'm only -0 on doing that for 3.2 rather than -1.

I'm -1 because we would alter the standard library to use this functionality
which would make it incompatible with other implementations. That is of
course unless Guido says we should add it anyway ;)

We might create a separate issue superseding #2651 which will be all about
presenting sensible named arguments for built-in exceptions. Does this sound
like a good plan?

-- 
Best regards,
?ukasz Langa
tel. +48 791 080 144
WWW http://lukasz.langa.pl/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100805/a47d8dc6/attachment.html>

From barry at python.org  Thu Aug  5 00:27:44 2010
From: barry at python.org (Barry Warsaw)
Date: Wed, 4 Aug 2010 18:27:44 -0400
Subject: [Python-Dev] Python 2.6.6 release candidate 1 now available
Message-ID: <20100804182744.4a473a38@heresy>

Hello fellow Pythoneers and Pythonistas,

The source tarballs and Windows installers for the first (and hopefully only)
Python 2.6.6 release candidate is now available:

    http://www.python.org/download/releases/2.6.6/

As usual, we would love it if you could download, install, and test these with
your favorite projects and environments.  A truly impressive number of bug
have been fixed since Python 2.6.5, with the full NEWS file available here:

    http://www.python.org/download/releases/2.6.6/NEWS.txt

Barring complications, we expect to release Python 2.6.6 final on August 16,
2010.

Please note that with the release of Python 2.7 final on July 3, 2010, and in
accordance with Python policy, Python 2.6.6 is the last scheduled bug fix
maintenance release of the 2.6 series.  Because of this, your testing of this
release candidate will help immensely.  We will of course continue to support
security fixes in Python 2.6 for quite some time.

My thanks go out to everyone who has helped contribute fixes great and small,
and much testing and bug tracker gardening for Python 2.6.6.  The excellent
folks on #python-dev are true Pythonic heros too.

Enjoy,
-Barry
(on behalf of the Python development community)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100804/cda7705c/attachment.pgp>

From eric at trueblade.com  Thu Aug  5 00:33:05 2010
From: eric at trueblade.com (Eric Smith)
Date: Wed, 04 Aug 2010 18:33:05 -0400
Subject: [Python-Dev] #2651 - KeyError does not round trip strings
In-Reply-To: <AANLkTinE3UjLUZEYqMmkwnktwmY8HfRY2nyLYAWVQnh3@mail.gmail.com>
References: <96448358-C3F6-4012-94FC-CAAE8D0F18D9@langa.pl>	<AANLkTikEA9v2fNo_1HHH162C391bNM9DpoPnJzEj1Dy9@mail.gmail.com>	<AANLkTi=72-K=me-xr+U3_KxVE_sS4yNDfwCibmBpOOPA@mail.gmail.com>	<AANLkTi=dD5yqPjs7potXNXCteD5U4Mo1FVwGAdoZFhCY@mail.gmail.com>
	<AANLkTinE3UjLUZEYqMmkwnktwmY8HfRY2nyLYAWVQnh3@mail.gmail.com>
Message-ID: <4C59EAA1.7090207@trueblade.com>

On 8/4/2010 6:09 PM, Nick Coghlan wrote:
> On Thu, Aug 5, 2010 at 8:02 AM, Fred Drake<fdrake at acm.org>  wrote:
>> On Wed, Aug 4, 2010 at 5:57 PM, Nick Coghlan<ncoghlan at gmail.com>  wrote:
>>> and use a default message of
>>> "'Key not found: %r' % key" if the key argument is supplied without an
>>> explicit message
>>
>> I suspect you meant a default message of
>>
>>     'Key not found: %r' % (key,)
>>
>> since `key` might be a 1-tuple.  :-)
>
> Gah, you're right.
>
> Maybe I should have said "'Key not found: {}'.format(key)" :)

'Key not found: {!r}'.format(key)

Eric.

From solipsis at pitrou.net  Thu Aug  5 00:38:52 2010
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Thu, 5 Aug 2010 00:38:52 +0200
Subject: [Python-Dev] #2651 - KeyError does not round trip strings
References: <96448358-C3F6-4012-94FC-CAAE8D0F18D9@langa.pl>
	<AANLkTikEA9v2fNo_1HHH162C391bNM9DpoPnJzEj1Dy9@mail.gmail.com>
	<AANLkTi=72-K=me-xr+U3_KxVE_sS4yNDfwCibmBpOOPA@mail.gmail.com>
Message-ID: <20100805003852.508397c5@pitrou.net>

On Thu, 5 Aug 2010 07:57:07 +1000
Nick Coghlan <ncoghlan at gmail.com> wrote:
> 
> +1 on what Fred said (i.e. post-moratorium, add a keyword-only "key"
> argument to KeyError, set "e.key" only if that argument is supplied,
> update the standard library to supply it and use a default message of
> "'Key not found: %r' % key" if the key argument is supplied without an
> explicit message). Also +1 for doing the equivalent with
> AttributeError and an "attr" keyword only argument.

Keyword-only arguments are rather annoying to use from C code, though.

Regards

Antoine.



From steve at holdenweb.com  Thu Aug  5 00:39:26 2010
From: steve at holdenweb.com (Steve Holden)
Date: Wed, 04 Aug 2010 18:39:26 -0400
Subject: [Python-Dev] Looking after the buildbots (in general)
In-Reply-To: <i3cooc$p7b$1@dough.gmane.org>
References: <i3aeij$146$1@dough.gmane.org>	<20100804111613.4e1273f7@pitrou.net>	<20100804105119.6ae19dc3@heresy>	<20100804151553.2305.954819342.divmod.xquotient.83@localhost.localdomain>	<20100804113140.03aaf80b@heresy>	<20100804164225.2305.654532857.divmod.xquotient.91@localhost.localdomain>	<i3c9kn$uje$1@dough.gmane.org>
	<i3cooc$p7b$1@dough.gmane.org>
Message-ID: <4C59EC1E.6000307@holdenweb.com>

On 8/4/2010 6:11 PM, Georg Brandl wrote:
> Am 04.08.2010 19:56, schrieb Steve Holden:
> 
>> This whole discussion seems to make it clear that the release manager
>> procedures are still ill-defined in certain areas.
> 
> If you mean to imply that a release manager should care for the stability
> of "their" branch also in between of releases -- I'd love to do that,
> but I'd need a 36-hour day then.
> 
I'll see if I can get God to extend it for you. I honestly do understand
that everyone else works under the same restrictions of time that I do
... and I appreciate all the hard work the release managers continue to
put in.

regards
 Steve
-- 
Steve Holden           +1 571 484 6266   +1 800 494 3119
DjangoCon US September 7-9, 2010    http://djangocon.us/
See Python Video!       http://python.mirocommunity.org/
Holden Web LLC                 http://www.holdenweb.com/

From steve at holdenweb.com  Thu Aug  5 00:39:26 2010
From: steve at holdenweb.com (Steve Holden)
Date: Wed, 04 Aug 2010 18:39:26 -0400
Subject: [Python-Dev] Looking after the buildbots (in general)
In-Reply-To: <i3cooc$p7b$1@dough.gmane.org>
References: <i3aeij$146$1@dough.gmane.org>	<20100804111613.4e1273f7@pitrou.net>	<20100804105119.6ae19dc3@heresy>	<20100804151553.2305.954819342.divmod.xquotient.83@localhost.localdomain>	<20100804113140.03aaf80b@heresy>	<20100804164225.2305.654532857.divmod.xquotient.91@localhost.localdomain>	<i3c9kn$uje$1@dough.gmane.org>
	<i3cooc$p7b$1@dough.gmane.org>
Message-ID: <4C59EC1E.6000307@holdenweb.com>

On 8/4/2010 6:11 PM, Georg Brandl wrote:
> Am 04.08.2010 19:56, schrieb Steve Holden:
> 
>> This whole discussion seems to make it clear that the release manager
>> procedures are still ill-defined in certain areas.
> 
> If you mean to imply that a release manager should care for the stability
> of "their" branch also in between of releases -- I'd love to do that,
> but I'd need a 36-hour day then.
> 
I'll see if I can get God to extend it for you. I honestly do understand
that everyone else works under the same restrictions of time that I do
... and I appreciate all the hard work the release managers continue to
put in.

regards
 Steve
-- 
Steve Holden           +1 571 484 6266   +1 800 494 3119
DjangoCon US September 7-9, 2010    http://djangocon.us/
See Python Video!       http://python.mirocommunity.org/
Holden Web LLC                 http://www.holdenweb.com/


From greg.ewing at canterbury.ac.nz  Thu Aug  5 01:11:04 2010
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Thu, 05 Aug 2010 11:11:04 +1200
Subject: [Python-Dev] Drive suffix
In-Reply-To: <AANLkTimCndKJycuE52+zND4bGk6NEe1i35Mb_P8ZvEzp@mail.gmail.com>
References: <BD56C6C87FA349439871663F1FB3307D@robslaptop>
	<AANLkTi=7_bewh97XuvM21sW-V7GNTMCq6_KLhVHoT5CF@mail.gmail.com>
	<AANLkTimCndKJycuE52+zND4bGk6NEe1i35Mb_P8ZvEzp@mail.gmail.com>
Message-ID: <4C59F388.6060407@canterbury.ac.nz>

James Mills wrote:
> Windows
> is one of the only Operating Systems with a File system that reuiqres
> this [A-Z]:\ syntax.

There's also VMS, but it uses a colon too. Also its
pathnames are funky enough in other ways that it
needs its own os-specific pathname routines.

I'm not aware of any system that's "just like Windows"
except that it uses something other than colons.

-- 
Greg

From barry at python.org  Thu Aug  5 01:26:06 2010
From: barry at python.org (Barry Warsaw)
Date: Wed, 4 Aug 2010 19:26:06 -0400
Subject: [Python-Dev] Looking after the buildbots (in general)
In-Reply-To: <4C59EC1E.6000307@holdenweb.com>
References: <i3aeij$146$1@dough.gmane.org> <20100804111613.4e1273f7@pitrou.net>
	<20100804105119.6ae19dc3@heresy>
	<20100804151553.2305.954819342.divmod.xquotient.83@localhost.localdomain>
	<20100804113140.03aaf80b@heresy>
	<20100804164225.2305.654532857.divmod.xquotient.91@localhost.localdomain>
	<i3c9kn$uje$1@dough.gmane.org> <i3cooc$p7b$1@dough.gmane.org>
	<4C59EC1E.6000307@holdenweb.com>
Message-ID: <20100804192606.2f92a3c5@heresy>

On Aug 04, 2010, at 06:39 PM, Steve Holden wrote:

>I'll see if I can get God to extend it for you.

No need to involve the supernatural Steve!  Just approve that PSF grant I
submitted so I can finish my (Python powered of course!) clone army.

>I honestly do understand that everyone else works under the same restrictions
>of time that I do ... and I appreciate all the hard work the release managers
>continue to put in.

We know you love us Steve. :)

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100804/6d3e3cae/attachment.pgp>

From jstpierre at mecheye.net  Thu Aug  5 00:48:39 2010
From: jstpierre at mecheye.net (Jasper St. Pierre)
Date: Wed, 4 Aug 2010 18:48:39 -0400
Subject: [Python-Dev] barry_as_FLUFL
Message-ID: <AANLkTi=2AiwXaH8mFFK008neizF0iYKvxEA3X2tLvptu@mail.gmail.com>

I was fooling around with Python 3.1 today, and I found this little nugget:

>>> import __future__
>>> dir(__future__)
['CO_FUTURE_ABSOLUTE_IMPORT', 'CO_FUTURE_BARRY_AS_BDFL',
'CO_FUTURE_DIVISION', 'CO_FUTURE_PRINT_FUNCTION',
'CO_FUTURE_UNICODE_LITERALS', 'CO_FUTURE_WITH_STATEMENT',
'CO_GENERATOR_ALLOWED', 'CO_NESTED', '_Feature', '__all__',
'__builtins__', '__doc__', '__file__', '__name__', '__package__',
'absolute_import', 'all_feature_names', 'barry_as_FLUFL', 'division',
'generators', 'nested_scopes', 'print_function', 'unicode_literals',
'with_statement']

hmm... BARRY_AS_BDFL and barry_as_FLUFL

>>> from __future__ import barry_as_FLUFL
>>>

nothing noticable happened. I googled the latter, and found that it's an April
Fools (of 2009!) checkin that was never reverted.

http://mail.python.org/pipermail/python-checkins/2009-April/080796.html

From merwok at netwok.org  Thu Aug  5 02:16:12 2010
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Thu, 05 Aug 2010 02:16:12 +0200
Subject: [Python-Dev] barry_as_FLUFL
In-Reply-To: <AANLkTi=2AiwXaH8mFFK008neizF0iYKvxEA3X2tLvptu@mail.gmail.com>
References: <AANLkTi=2AiwXaH8mFFK008neizF0iYKvxEA3X2tLvptu@mail.gmail.com>
Message-ID: <4C5A02CC.6090601@netwok.org>

Hello


> hmm... BARRY_AS_BDFL and barry_as_FLUFL

Oh, bad consistency. Should have been BARRY_AS_FLUFL and barry_as_flufl.

>>>> from __future__ import barry_as_FLUFL
> nothing noticable happened.

I made some tests about that and found that the behavior didn?t match
the PEP; I have to redo experiments and eventually report bugs.

> I googled the latter, and found that it's an April
> Fools (of 2009!) checkin that was never reverted.

Why should it be reverted? It causes no harm.


Regards


P.S. from __future__ import braces


From guido at python.org  Thu Aug  5 02:16:05 2010
From: guido at python.org (Guido van Rossum)
Date: Wed, 4 Aug 2010 17:16:05 -0700
Subject: [Python-Dev] barry_as_FLUFL
In-Reply-To: <AANLkTi=2AiwXaH8mFFK008neizF0iYKvxEA3X2tLvptu@mail.gmail.com>
References: <AANLkTi=2AiwXaH8mFFK008neizF0iYKvxEA3X2tLvptu@mail.gmail.com>
Message-ID: <AANLkTikhP6XJiFUDkMu6CAO2jJJmR0uXYWOadNR_Ut0+@mail.gmail.com>

On Wed, Aug 4, 2010 at 3:48 PM, Jasper St. Pierre <jstpierre at mecheye.net> wrote:
> I was fooling around with Python 3.1 today, and I found this little nugget:
>
>>>> import __future__
>>>> dir(__future__)
> ['CO_FUTURE_ABSOLUTE_IMPORT', 'CO_FUTURE_BARRY_AS_BDFL',
> 'CO_FUTURE_DIVISION', 'CO_FUTURE_PRINT_FUNCTION',
> 'CO_FUTURE_UNICODE_LITERALS', 'CO_FUTURE_WITH_STATEMENT',
> 'CO_GENERATOR_ALLOWED', 'CO_NESTED', '_Feature', '__all__',
> '__builtins__', '__doc__', '__file__', '__name__', '__package__',
> 'absolute_import', 'all_feature_names', 'barry_as_FLUFL', 'division',
> 'generators', 'nested_scopes', 'print_function', 'unicode_literals',
> 'with_statement']
>
> hmm... BARRY_AS_BDFL and barry_as_FLUFL
>
>>>> from __future__ import barry_as_FLUFL
>>>>
>
> nothing noticable happened. I googled the latter, and found that it's an April
> Fools (of 2009!) checkin that was never reverted.

We don't revert our April Fool's checkins. Easter eggs are forever!

-- 
--Guido van Rossum (python.org/~guido)

From barry at python.org  Thu Aug  5 03:12:40 2010
From: barry at python.org (Barry Warsaw)
Date: Wed, 4 Aug 2010 21:12:40 -0400
Subject: [Python-Dev] barry_as_FLUFL
In-Reply-To: <AANLkTi=2AiwXaH8mFFK008neizF0iYKvxEA3X2tLvptu@mail.gmail.com>
References: <AANLkTi=2AiwXaH8mFFK008neizF0iYKvxEA3X2tLvptu@mail.gmail.com>
Message-ID: <20100804211240.40539f33@heresy>

On Aug 04, 2010, at 06:48 PM, Jasper St. Pierre wrote:

>hmm... BARRY_AS_BDFL and barry_as_FLUFL

[...]

>nothing noticable happened. I googled the latter, and found that it's
>an April Fools (of 2009!) checkin that was never reverted.

Wait.  It's a joke?!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100804/3e688097/attachment.pgp>

From stephen at xemacs.org  Thu Aug  5 03:21:57 2010
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Thu, 05 Aug 2010 10:21:57 +0900
Subject: [Python-Dev] Drive suffix
In-Reply-To: <4C59F388.6060407@canterbury.ac.nz>
References: <BD56C6C87FA349439871663F1FB3307D@robslaptop>
	<AANLkTi=7_bewh97XuvM21sW-V7GNTMCq6_KLhVHoT5CF@mail.gmail.com>
	<AANLkTimCndKJycuE52+zND4bGk6NEe1i35Mb_P8ZvEzp@mail.gmail.com>
	<4C59F388.6060407@canterbury.ac.nz>
Message-ID: <8739utsvka.fsf@uwakimon.sk.tsukuba.ac.jp>

Greg Ewing writes:

 > I'm not aware of any system that's "just like Windows"
 > except that it uses something other than colons.

It's a shame that Windows machines can be networked; otherwise we
could formally treat drive letters as the scheme component of file
URLs.


From stephen at xemacs.org  Thu Aug  5 03:50:21 2010
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Thu, 05 Aug 2010 10:50:21 +0900
Subject: [Python-Dev] Looking after the buildbots (in general)
In-Reply-To: <i3c9kn$uje$1@dough.gmane.org>
References: <i3aeij$146$1@dough.gmane.org> <20100804111613.4e1273f7@pitrou.net>
	<20100804105119.6ae19dc3@heresy>
	<20100804151553.2305.954819342.divmod.xquotient.83@localhost.localdomain>
	<20100804113140.03aaf80b@heresy>
	<20100804164225.2305.654532857.divmod.xquotient.91@localhost.localdomain>
	<i3c9kn$uje$1@dough.gmane.org>
Message-ID: <871vadsu8y.fsf@uwakimon.sk.tsukuba.ac.jp>

Steve Holden writes:

 > But I see rules being established ("there's a language moratorium: no
 > changes!", "no release should be made unless the buildbots are *all*
 > green") and then ignored apparently on a whim. This doesn't give people
 > any confidence that the rules actually mean much, and I think ignoring
 > the latter rule can negatively affect quality.

I don't see this.  In the first case, you've misstated the rule: it's
"no changes to the Python language", and what is and is not part of
the language is subject to a certain amount of interpretation.  There
are several PEPs waiting on the moratorium despite everybody loving
them, and the decisions on borderline changes (which have gone both
ways, mostly denials) are establishing precedents that narrow the
scope for "interpretation".  I think it's very reasonable to assess
the moratorium as *very successful* with respect to it being a rule
that is obeyed in spirit and according to the letter.

In the second case, I don't recall it being stated as a project rule.
The buildbots were considered untrustworthy by many from the get-go,
and I do recall discussion of the "community buildbots" which
effectively resulted in community 'bots being fully deprecated.

Some RMs have nevertheless chosen to take them very seriously and want
them fixed if they're broken, others consider them a useful indicator
but are willing to proceed if there are strong indications that the
'bot is broken rather than CPython.  That's something that can be left
up to the release manager or not, as the project chooses, but my
impression to date has been that this is a matter of RM policy, not
project policy.

Note that following the latter rule can also negatively affect
quality, if scarce developer effort is devoted to fixing somebody
else's software rather than working on Python.

FWIW my assessment is that for the moment all of the RMs take the
buildbots pretty seriously, which is good (that seems to be consensus
opinion), with some variations in intensity, which is also (IMO YMMV)
good.  No need for change here yet (IMO YMMV), although community
members (anybody who cares) should prod RMs who seem to be neglecting
buildbot results.  In another cycle or so, the bots will probably be
ready for a project-wide rule.

I agree with J-P's suggestion that the place to start is asking
developers to bookmark the bot pages relevant to them, and visit it
(with appropriate lag) after committing.  For one thing, if people see
the 'bots deprecating their perfectly good changes, they'll have some
incentive to work on the bots and beat them into shape.  That can help
take some load off the people who have concentrated on the bots.  It
will also mean that a decision to condition releases on green bots
will be taken based on much broader experience rather than hearsay
about their reliability.

From ben+python at benfinney.id.au  Thu Aug  5 04:27:44 2010
From: ben+python at benfinney.id.au (Ben Finney)
Date: Thu, 05 Aug 2010 12:27:44 +1000
Subject: [Python-Dev] barry_as_FLUFL
References: <AANLkTi=2AiwXaH8mFFK008neizF0iYKvxEA3X2tLvptu@mail.gmail.com>
	<20100804211240.40539f33@heresy>
Message-ID: <878w4l3ian.fsf@benfinney.id.au>

Barry Warsaw <barry at python.org> writes:

> On Aug 04, 2010, at 06:48 PM, Jasper St. Pierre wrote:
> >hmm... BARRY_AS_BDFL and barry_as_FLUFL
> [...]
>
> >nothing noticable happened. I googled the latter, and found that it's
> >an April Fools (of 2009!) checkin that was never reverted.
>
> Wait.  It's a joke?!

That doesn't mean it's not true :-)

this-hacker-for-one-welcomes-our-great-FLUFL-'ly yrs,

-- 
 \            ?? Nature ? is seen to do all things Herself and through |
  `\         herself of own accord, rid of all gods.? ?Titus Lucretius |
_o__)                                                 Carus, c. 40 BCE |
Ben Finney
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100805/d9d45e08/attachment.pgp>

From ben+python at benfinney.id.au  Thu Aug  5 04:29:23 2010
From: ben+python at benfinney.id.au (Ben Finney)
Date: Thu, 05 Aug 2010 12:29:23 +1000
Subject: [Python-Dev] Drive suffix
References: <BD56C6C87FA349439871663F1FB3307D@robslaptop>
	<AANLkTi=7_bewh97XuvM21sW-V7GNTMCq6_KLhVHoT5CF@mail.gmail.com>
	<AANLkTimCndKJycuE52+zND4bGk6NEe1i35Mb_P8ZvEzp@mail.gmail.com>
	<4C59F388.6060407@canterbury.ac.nz>
	<8739utsvka.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <874of93i7w.fsf@benfinney.id.au>

"Stephen J. Turnbull" <stephen at xemacs.org> writes:

> It's a shame that Windows machines can be networked

+1 QOTW

Even if QOTW doesn't work in this forum, I still cast my vote.

-- 
 \     ?We should strive to do things in [Gandhi's] spirit? not to use |
  `\   violence in fighting for our cause, but by non-participation in |
_o__)                       what we believe is evil.? ?Albert Einstein |
Ben Finney


From fdrake at acm.org  Thu Aug  5 07:35:22 2010
From: fdrake at acm.org (Fred Drake)
Date: Thu, 5 Aug 2010 01:35:22 -0400
Subject: [Python-Dev] #2651 - KeyError does not round trip strings
In-Reply-To: <248F23EA-BACA-4936-8D04-F4BBDF930CE9@langa.pl>
References: <96448358-C3F6-4012-94FC-CAAE8D0F18D9@langa.pl> 
	<AANLkTikEA9v2fNo_1HHH162C391bNM9DpoPnJzEj1Dy9@mail.gmail.com> 
	<AANLkTi=72-K=me-xr+U3_KxVE_sS4yNDfwCibmBpOOPA@mail.gmail.com> 
	<248F23EA-BACA-4936-8D04-F4BBDF930CE9@langa.pl>
Message-ID: <AANLkTikX12b0TcAA1Vpb4CMSPuFomNvztB2qePa6EeAN@mail.gmail.com>

2010/8/4 ?ukasz Langa <lukasz at langa.pl>:
> Shall we do an e.index for IndexErrors as well?

I don't recall stumbling over that need, but the parallel makes it
tempting.  I expect is should be a separate patch, though.

Antoine's right about using keyword args from C, though.  I'd expect a
new helper function that handles this specific case, since it's likely
to be common.  Whether it used a keyword are or just performed a
setattr after the exception is created doesn't really matter.


? -Fred

--
Fred L. Drake, Jr.? ? <fdrake at gmail.com>
"A storm broke loose in my mind."? --Albert Einstein

From martin at v.loewis.de  Thu Aug  5 07:45:31 2010
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 05 Aug 2010 07:45:31 +0200
Subject: [Python-Dev] Looking after the buildbots (in general)
In-Reply-To: <4C59EC1E.6000307@holdenweb.com>
References: <i3aeij$146$1@dough.gmane.org>	<20100804111613.4e1273f7@pitrou.net>	<20100804105119.6ae19dc3@heresy>	<20100804151553.2305.954819342.divmod.xquotient.83@localhost.localdomain>	<20100804113140.03aaf80b@heresy>	<20100804164225.2305.654532857.divmod.xquotient.91@localhost.localdomain>	<i3c9kn$uje$1@dough.gmane.org>	<i3cooc$p7b$1@dough.gmane.org>
	<4C59EC1E.6000307@holdenweb.com>
Message-ID: <4C5A4FFB.90509@v.loewis.de>

>> If you mean to imply that a release manager should care for the stability
>> of "their" branch also in between of releases -- I'd love to do that,
>> but I'd need a 36-hour day then.
>>
> I'll see if I can get God to extend it for you. I honestly do understand
> that everyone else works under the same restrictions of time that I do
> ... and I appreciate all the hard work the release managers continue to
> put in.

And indeed, from an RM point of view, fixing the bugs that cause
buildbot breakage isn't the right action for the RM.

Instead, if the release procedures say that the buildbots must pass the
test, and the tests don't actually pass, the natural consequence is not
to release. Barry has often exercised that approach in the past, and in
many cases, it actually helped in getting people motivated to fix bugs
when he threatened not to release.

Regards,
Martin

From g.brandl at gmx.net  Thu Aug  5 08:19:51 2010
From: g.brandl at gmx.net (Georg Brandl)
Date: Thu, 05 Aug 2010 08:19:51 +0200
Subject: [Python-Dev] Looking after the buildbots (in general)
In-Reply-To: <20100804192606.2f92a3c5@heresy>
References: <i3aeij$146$1@dough.gmane.org>
	<20100804111613.4e1273f7@pitrou.net>	<20100804105119.6ae19dc3@heresy>	<20100804151553.2305.954819342.divmod.xquotient.83@localhost.localdomain>	<20100804113140.03aaf80b@heresy>	<20100804164225.2305.654532857.divmod.xquotient.91@localhost.localdomain>	<i3c9kn$uje$1@dough.gmane.org>
	<i3cooc$p7b$1@dough.gmane.org>	<4C59EC1E.6000307@holdenweb.com>
	<20100804192606.2f92a3c5@heresy>
Message-ID: <i3dlav$l7$1@dough.gmane.org>

Am 05.08.2010 01:26, schrieb Barry Warsaw:
> On Aug 04, 2010, at 06:39 PM, Steve Holden wrote:
> 
>>I'll see if I can get God to extend it for you.
> 
> No need to involve the supernatural Steve!  Just approve that PSF grant I
> submitted so I can finish my (Python powered of course!) clone army.

*Now* I know why the PSU abducted all these developers!  To assemble
a sufficient gene pool...

>>I honestly do understand that everyone else works under the same restrictions
>>of time that I do ... and I appreciate all the hard work the release managers
>>continue to put in.
> 
> We know you love us Steve. :)

In a PHBy way, it seems :)

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.


From cesare.di.mauro at gmail.com  Thu Aug  5 08:51:21 2010
From: cesare.di.mauro at gmail.com (Cesare Di Mauro)
Date: Thu, 5 Aug 2010 08:51:21 +0200
Subject: [Python-Dev] Drive suffix
In-Reply-To: <4C59F388.6060407@canterbury.ac.nz>
References: <BD56C6C87FA349439871663F1FB3307D@robslaptop>
	<AANLkTi=7_bewh97XuvM21sW-V7GNTMCq6_KLhVHoT5CF@mail.gmail.com>
	<AANLkTimCndKJycuE52+zND4bGk6NEe1i35Mb_P8ZvEzp@mail.gmail.com>
	<4C59F388.6060407@canterbury.ac.nz>
Message-ID: <AANLkTimycnekuRnQfuusNpmp-w437uEp_s2w--EdPkUx@mail.gmail.com>

2010/8/5 Greg Ewing <greg.ewing at canterbury.ac.nz>

> James Mills wrote:
>
>> Windows
>> is one of the only Operating Systems with a File system that reuiqres
>> this [A-Z]:\ syntax.
>>
>
> There's also VMS, but it uses a colon too. Also its
> pathnames are funky enough in other ways that it
> needs its own os-specific pathname routines.
>
> I'm not aware of any system that's "just like Windows"
> except that it uses something other than colons.
>
> --
> Greg


AmigaOS / AROS / MorphOS uses colon too as a volume (or device) separator:

dir "Ram Disk:System/Local Preferences"

Cesare
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100805/642cd161/attachment.html>

From eckhardt at satorlaser.com  Thu Aug  5 08:45:22 2010
From: eckhardt at satorlaser.com (Ulrich Eckhardt)
Date: Thu, 5 Aug 2010 08:45:22 +0200
Subject: [Python-Dev] Drive suffix
In-Reply-To: <C937871F81D7411289819D5D627A27C1@robslaptop>
References: <BD56C6C87FA349439871663F1FB3307D@robslaptop> 
	<AANLkTi=7_bewh97XuvM21sW-V7GNTMCq6_KLhVHoT5CF@mail.gmail.com> 
	<C937871F81D7411289819D5D627A27C1@robslaptop>
Message-ID: <201008050845.23079.eckhardt@satorlaser.com>

On Wednesday 04 August 2010, Rob Cliffe wrote:
> As it happens, what sparked the question was trying to determine in a
> platform-independent way whether a path consisted of a bare drive
> specification (e.g. "C:").  I guess
>     os.path.splitdrive(MyPath)[1] == ""
> takes care of that.

"platform-independent"? What is a "bare drive specification" on a FreeBSD 
system? Do you perhaps mean "mount point" instead? I don't think this 
discussion belongs Here(tm) though.

BTW: Embedded MS Windows CE uses a filesystem tree like *nix, i.e. without 
drive letters. Not that I have any kind of Python crawling on one of those 
yet, just wanted to mention...

Uli

-- 
Sator Laser GmbH, Fangdieckstra?e 75a, 22547 Hamburg, Deutschland
Gesch?ftsf?hrer: Thorsten F?cking, Amtsgericht Hamburg HR B62 932

**************************************************************************************
Sator Laser GmbH, Fangdieckstra?e 75a, 22547 Hamburg, Deutschland
Gesch?ftsf?hrer: Thorsten F?cking, Amtsgericht Hamburg HR B62 932
**************************************************************************************
           Visit our website at <http://www.satorlaser.de/>
**************************************************************************************
Diese E-Mail einschlie?lich s?mtlicher Anh?nge ist nur f?r den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empf?nger sein sollten. Die E-Mail ist in diesem Fall zu l?schen und darf weder gelesen, weitergeleitet, ver?ffentlicht oder anderweitig benutzt werden.
E-Mails k?nnen durch Dritte gelesen werden und Viren sowie nichtautorisierte ?nderungen enthalten. Sator Laser GmbH ist f?r diese Folgen nicht verantwortlich.
**************************************************************************************


From jon+python-dev at unequivocal.co.uk  Thu Aug  5 10:57:04 2010
From: jon+python-dev at unequivocal.co.uk (Jon Ribbens)
Date: Thu, 5 Aug 2010 09:57:04 +0100
Subject: [Python-Dev] Looking after the buildbots (in general)
In-Reply-To: <20100804192606.2f92a3c5@heresy>
References: <i3aeij$146$1@dough.gmane.org> <20100804111613.4e1273f7@pitrou.net>
	<20100804105119.6ae19dc3@heresy>
	<20100804151553.2305.954819342.divmod.xquotient.83@localhost.localdomain>
	<20100804113140.03aaf80b@heresy>
	<20100804164225.2305.654532857.divmod.xquotient.91@localhost.localdomain>
	<i3c9kn$uje$1@dough.gmane.org> <i3cooc$p7b$1@dough.gmane.org>
	<4C59EC1E.6000307@holdenweb.com> <20100804192606.2f92a3c5@heresy>
Message-ID: <20100805085704.GY29810@snowy.squish.net>

On Wed, Aug 04, 2010 at 07:26:06PM -0400, Barry Warsaw wrote:
> On Aug 04, 2010, at 06:39 PM, Steve Holden wrote:
> >I'll see if I can get God to extend it for you.
> 
> No need to involve the supernatural Steve!  Just approve that PSF grant I
> submitted so I can finish my (Python powered of course!) clone army.

Someone else got there ahead of you...
http://en.wikipedia.org/wiki/MASSIVE_%28software%29

From greg.ewing at canterbury.ac.nz  Thu Aug  5 12:22:57 2010
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Thu, 05 Aug 2010 22:22:57 +1200
Subject: [Python-Dev] barry_as_FLUFL
In-Reply-To: <20100804211240.40539f33@heresy>
References: <AANLkTi=2AiwXaH8mFFK008neizF0iYKvxEA3X2tLvptu@mail.gmail.com>
	<20100804211240.40539f33@heresy>
Message-ID: <4C5A9101.4000904@canterbury.ac.nz>

Barry Warsaw wrote:

> Wait.  It's a joke?!

Probably, but it's also useful behaviour -- I hope
it stays!

(Not that I would ever presume to use it in any
code inflicted on anyone else, but it's nice to
know I have a choice in the privacy of my own
computer.)

Heil-the-FLUFl-ly,
Greg

From steve at holdenweb.com  Thu Aug  5 13:49:31 2010
From: steve at holdenweb.com (Steve Holden)
Date: Thu, 05 Aug 2010 07:49:31 -0400
Subject: [Python-Dev] Looking after the buildbots (in general)
In-Reply-To: <i3dlav$l7$1@dough.gmane.org>
References: <i3aeij$146$1@dough.gmane.org>	<20100804111613.4e1273f7@pitrou.net>	<20100804105119.6ae19dc3@heresy>	<20100804151553.2305.954819342.divmod.xquotient.83@localhost.localdomain>	<20100804113140.03aaf80b@heresy>	<20100804164225.2305.654532857.divmod.xquotient.91@localhost.localdomain>	<i3c9kn$uje$1@dough.gmane.org>	<i3cooc$p7b$1@dough.gmane.org>	<4C59EC1E.6000307@holdenweb.com>	<20100804192606.2f92a3c5@heresy>
	<i3dlav$l7$1@dough.gmane.org>
Message-ID: <i3e8gd$tnj$1@dough.gmane.org>

On 8/5/2010 2:19 AM, Georg Brandl wrote:
> Am 05.08.2010 01:26, schrieb Barry Warsaw:
>> On Aug 04, 2010, at 06:39 PM, Steve Holden wrote:
>>
>>> I'll see if I can get God to extend it for you.
>>
>> No need to involve the supernatural Steve!  Just approve that PSF grant I
>> submitted so I can finish my (Python powered of course!) clone army.
> 
> *Now* I know why the PSU abducted all these developers!  To assemble
> a sufficient gene pool...
> 
>>> I honestly do understand that everyone else works under the same restrictions
>>> of time that I do ... and I appreciate all the hard work the release managers
>>> continue to put in.
>>
>> We know you love us Steve. :)
> 
> In a PHBy way, it seems :)
> 
I'd have thought a pre-requisite for being a PHB was having hair.

regards
 Steve
-- 
Steve Holden           +1 571 484 6266   +1 800 494 3119
DjangoCon US September 7-9, 2010    http://djangocon.us/
See Python Video!       http://python.mirocommunity.org/
Holden Web LLC                 http://www.holdenweb.com/


From phd at phd.pp.ru  Thu Aug  5 14:12:16 2010
From: phd at phd.pp.ru (Oleg Broytman)
Date: Thu, 5 Aug 2010 16:12:16 +0400
Subject: [Python-Dev] OT: PHB (was: Looking after the buildbots)
In-Reply-To: <i3e8gd$tnj$1@dough.gmane.org>
References: <20100804105119.6ae19dc3@heresy>
	<20100804151553.2305.954819342.divmod.xquotient.83@localhost.localdomain>
	<20100804113140.03aaf80b@heresy>
	<20100804164225.2305.654532857.divmod.xquotient.91@localhost.localdomain>
	<i3c9kn$uje$1@dough.gmane.org> <i3cooc$p7b$1@dough.gmane.org>
	<4C59EC1E.6000307@holdenweb.com>
	<20100804192606.2f92a3c5@heresy> <i3dlav$l7$1@dough.gmane.org>
	<i3e8gd$tnj$1@dough.gmane.org>
Message-ID: <20100805121216.GB25734@phd.pp.ru>

On Thu, Aug 05, 2010 at 07:49:31AM -0400, Steve Holden wrote:
> I'd have thought a pre-requisite for being a PHB was having hair.

   Not at all, not at all - being a PHB is a style of thinking, not
hairdressing. ;)

Oleg.
-- 
     Oleg Broytman            http://phd.pp.ru/            phd at phd.pp.ru
           Programmers don't die, they just GOSUB without RETURN.

From steve at holdenweb.com  Thu Aug  5 14:34:47 2010
From: steve at holdenweb.com (Steve Holden)
Date: Thu, 05 Aug 2010 08:34:47 -0400
Subject: [Python-Dev] OT: PHB
In-Reply-To: <20100805121216.GB25734@phd.pp.ru>
References: <20100804105119.6ae19dc3@heresy>	<20100804151553.2305.954819342.divmod.xquotient.83@localhost.localdomain>	<20100804113140.03aaf80b@heresy>	<20100804164225.2305.654532857.divmod.xquotient.91@localhost.localdomain>	<i3c9kn$uje$1@dough.gmane.org>
	<i3cooc$p7b$1@dough.gmane.org>	<4C59EC1E.6000307@holdenweb.com>	<20100804192606.2f92a3c5@heresy>
	<i3dlav$l7$1@dough.gmane.org>	<i3e8gd$tnj$1@dough.gmane.org>
	<20100805121216.GB25734@phd.pp.ru>
Message-ID: <i3eb5a$7ra$1@dough.gmane.org>

On 8/5/2010 8:12 AM, Oleg Broytman wrote:
> On Thu, Aug 05, 2010 at 07:49:31AM -0400, Steve Holden wrote:
>> I'd have thought a pre-requisite for being a PHB was having hair.
> 
>    Not at all, not at all - being a PHB is a style of thinking, not
> hairdressing. ;)
> 
I was simply trying to avoid becoming "The Python PHB" in the folklore.
Sadly I see it is now inevitable - thanks, Georg ;-)

regards
 Steve
-- 
Steve Holden           +1 571 484 6266   +1 800 494 3119
DjangoCon US September 7-9, 2010    http://djangocon.us/
See Python Video!       http://python.mirocommunity.org/
Holden Web LLC                 http://www.holdenweb.com/


From ncoghlan at gmail.com  Thu Aug  5 14:44:49 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 5 Aug 2010 22:44:49 +1000
Subject: [Python-Dev] #2651 - KeyError does not round trip strings
In-Reply-To: <AANLkTikX12b0TcAA1Vpb4CMSPuFomNvztB2qePa6EeAN@mail.gmail.com>
References: <96448358-C3F6-4012-94FC-CAAE8D0F18D9@langa.pl>
	<AANLkTikEA9v2fNo_1HHH162C391bNM9DpoPnJzEj1Dy9@mail.gmail.com>
	<AANLkTi=72-K=me-xr+U3_KxVE_sS4yNDfwCibmBpOOPA@mail.gmail.com>
	<248F23EA-BACA-4936-8D04-F4BBDF930CE9@langa.pl>
	<AANLkTikX12b0TcAA1Vpb4CMSPuFomNvztB2qePa6EeAN@mail.gmail.com>
Message-ID: <AANLkTi=PKWGFxfwCMdRWoW_C-FR794utPCeBTQ89MZhT@mail.gmail.com>

2010/8/5 Fred Drake <fdrake at acm.org>:
> 2010/8/4 ?ukasz Langa <lukasz at langa.pl>:
>> Shall we do an e.index for IndexErrors as well?
>
> I don't recall stumbling over that need, but the parallel makes it
> tempting. ?I expect is should be a separate patch, though.
>
> Antoine's right about using keyword args from C, though. ?I'd expect a
> new helper function that handles this specific case, since it's likely
> to be common. ?Whether it used a keyword are or just performed a
> setattr after the exception is created doesn't really matter.

Yeah, helper functions for C code that accepted the extra arguments
would do the trick.

I actually had a look to see what IOError does with its attributes and
I think it qualifies as being a little on the special side (replicated
in both 2.6 and the py3k branch):

>>> io1 = IOError(1)
>>> io2 = IOError(1, 2)
>>> io3 = IOError(1, 2, 3)
>>> io4 = IOError(1, 2, 3, 4)
>>> io1, io2, io3, io4
(IOError(1,), IOError(1, 2), IOError(1, 2), IOError(1, 2, 3, 4))
>>> io1.errno, io2.errno, io3.errno, io4.errno
(None, 1, 1, None)
>>> io1.strerror, io2.strerror, io3.strerror, io4.strerror
(None, 2, 2, None)
>>> io1.filename, io2.filename, io3.filename, io4.filename
(None, None, 3, None)

One argument = no attributes set
Two arguments = errno, strerror set (including if second argument is
explicitly None)
Three arguments = errno, strerror, filename set
Four or more arguments = no attributes set

Keyword arguments are not supported by IOError (or EnvironmentError,
which is where the above behaviour is actually implemented).

That precedent would deem it acceptable to adopt a backwards
compatible protocol that still allowed arbitrary positional arguments
for Key/Attribute/IndexError, but treated the 2 argument case
specially.

However, the IOError behaviour really doesn't strike me as a
particularly good example for us to be following, so PEP 3151 may want
to consider the issue of tidying up those exception signatures.

The "right" way to go still appears to be to allow arbitrary
positional arguments (which go into .args) for backwards
compatibility, then add appropriate keyword-only arguments. IOError
could get some keyword only arguments as well, retaining the somewhat
odd behaviour above for backwards compatibility reasons (although the
repr in the 3 argument case should be fixed).

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From merwok at netwok.org  Thu Aug  5 18:06:59 2010
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Thu, 05 Aug 2010 18:06:59 +0200
Subject: [Python-Dev] PEP 376 proposed changes for basic plugins support
In-Reply-To: <4C57F8CC.8000708@voidspace.org.uk>
References: <AANLkTinyjMkF2n91zS+48n6B_gkp9szW_bH0XJgTDh7D@mail.gmail.com>	<4C55FF0F.3010702@voidspace.org.uk>	<AANLkTim1af-zWEYF4U-vTr6d+8HkqFCycMVmQYsqpDcN@mail.gmail.com>	<4C5609A3.3090008@voidspace.org.uk>	<AANLkTimU-OUh8fzFoRvHMsQOqVa+jsFTfPyZKeY=heVg@mail.gmail.com>	<20100802010616.5FD133A4758@sparrow.telecommunity.com>	<AANLkTi=UDktBHXeQTU6_ouPk2sfnmhztMLY9yjzZJHP7@mail.gmail.com>	<4C56B846.9090009@egenix.com>	<20100802123145.2305.1286368223.divmod.xquotient.3@localhost.localdomain>	<4C56C57C.4000800@voidspace.org.uk>	<4C571E42.9040408@egenix.com>	<4C57247F.5060105@voidspace.org.uk>	<4C572C93.4040207@egenix.com>	<20100802213104.E6EFC3A479B@sparrow.telecommunity.com>	<4C57D317.8080707@egenix.com>
	<4C57F8CC.8000708@voidspace.org.uk>
Message-ID: <4C5AE1A3.5020003@netwok.org>

Hello

Le 03/08/2010 13:09, Michael Foord a ?crit :
> On 03/08/2010 09:28, M.-A. Lemburg wrote:
>> P.J. Eby wrote:
>>> At 10:37 PM 8/2/2010 +0200, M.-A. Lemburg wrote:
>>>>> [idea about sqlite3 db for caching]
>>>> [distros won?t like it, the filesystem is the db]
>>> [the db is a cache, it does not replace the files]
>> [advantages of sqlite3 db]
> Sounds good as an "optional extra" (i.e. it should be safe to completely 
> delete the cache file and still have everything work) to me. If the API 
> for using the feature is worked out well first this could be done as a 
> behind the scenes optimisation...

FYI, the current implementation in the distutils2-augmented pkgutil uses
a cache (a function call memo) for functions that e.g. iterate over
dist-info directories (and optionally egg-info directories too) or get a
Distribution object representing an installed project. Tools that modify
the state of the installation can call a function to clear this cache.

A sqlite db would certainly speed things up; it could replace the
existing caching in distutils2 or be left to other tools.

Regards


From ldlandis at gmail.com  Thu Aug  5 18:25:17 2010
From: ldlandis at gmail.com (LD 'Gus' Landis)
Date: Thu, 5 Aug 2010 10:25:17 -0600
Subject: [Python-Dev] barry_as_FLUFL
In-Reply-To: <4C5A9101.4000904@canterbury.ac.nz>
References: <AANLkTi=2AiwXaH8mFFK008neizF0iYKvxEA3X2tLvptu@mail.gmail.com>
	<20100804211240.40539f33@heresy>
	<4C5A9101.4000904@canterbury.ac.nz>
Message-ID: <AANLkTi=jfUGJxk4VTrauTJme0Zimh5WdZzm+Gr=DTMG+@mail.gmail.com>

Hi,

  I just read an interesting article (interview with Fred Brooks).
  See: http://www.informit.com/articles/article.aspx?p=1600886

  Eoin: The book contains a lot of explicit and implicit advice for those
  who must manage design projects. What would your top three pieces
  of advice for such managers be?

  Fred:
  1. Choose a chief designer separate from the manager and give him
      authority over the design and your trust.
  2. Plan for the iterative discovery and screening of requirements.
  3. Prototype (or simulate with models, etc.) early and get real user
      feedback on real use scenarios early and often.

  I immediately thought of the Python "process" as a real life example
  of this working!  Fortunately too, the "crop" of "manager"s is also
  growing!

  Congratulations to all that have been part of this process!!

Cheers,
  --ldl

On Thu, Aug 5, 2010 at 4:22 AM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Barry Warsaw wrote:
>
>> Wait. ?It's a joke?!
>
> Probably, but it's also useful behaviour -- I hope
> it stays!
>
> (Not that I would ever presume to use it in any
> code inflicted on anyone else, but it's nice to
> know I have a choice in the privacy of my own
> computer.)
>
> Heil-the-FLUFl-ly,
> Greg
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/ldlandis%40gmail.com
>



-- 
---
NOTE: If it is important CALL ME - I may miss email,
which I do NOT normally check on weekends nor on
a regular basis during any other day.
---
LD Landis - N0YRQ - de la tierra del encanto
3960 Schooner Loop, Las Cruces, NM 88012
575-448-1763? N32 21'48.28" W106 46'5.80"

From ncoghlan at gmail.com  Thu Aug  5 22:57:11 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 6 Aug 2010 06:57:11 +1000
Subject: [Python-Dev] barry_as_FLUFL
In-Reply-To: <AANLkTi=jfUGJxk4VTrauTJme0Zimh5WdZzm+Gr=DTMG+@mail.gmail.com>
References: <AANLkTi=2AiwXaH8mFFK008neizF0iYKvxEA3X2tLvptu@mail.gmail.com>
	<20100804211240.40539f33@heresy>
	<4C5A9101.4000904@canterbury.ac.nz>
	<AANLkTi=jfUGJxk4VTrauTJme0Zimh5WdZzm+Gr=DTMG+@mail.gmail.com>
Message-ID: <AANLkTina5xkAjhrMDXXp3RL=2ZpWHdHkBSFUuLwR058U@mail.gmail.com>

On Fri, Aug 6, 2010 at 2:25 AM, LD 'Gus' Landis <ldlandis at gmail.com> wrote:
> Hi,
>
> ?I just read an interesting article (interview with Fred Brooks).
> ?See: http://www.informit.com/articles/article.aspx?p=1600886
>
> ?Eoin: The book contains a lot of explicit and implicit advice for those
> ?who must manage design projects. What would your top three pieces
> ?of advice for such managers be?
>
> ?Fred:
> ?1. Choose a chief designer separate from the manager and give him
> ? ? ?authority over the design and your trust.
> ?2. Plan for the iterative discovery and screening of requirements.
> ?3. Prototype (or simulate with models, etc.) early and get real user
> ? ? ?feedback on real use scenarios early and often.
>
> ?I immediately thought of the Python "process" as a real life example
> ?of this working! ?Fortunately too, the "crop" of "manager"s is also
> ?growing!

There's actually quite a lot open source and proprietary development
in general can learn from each other, but the fact that so many open
source developers *aren'* getting paid means that garbage that is
tolerated in a proprietary setting doesn't happen as much in open
source.

One random thing: the knowledge that your commits are going to be
broadcast immediately to anyone that is interested, as well as
archived permanently on the world wide web is a powerful incentive to:
a) write good code
b) comment anything that is hackish/tremendously complicated
c) write decent checkin messages

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From rdmurray at bitdance.com  Sat Aug  7 00:26:27 2010
From: rdmurray at bitdance.com (R. David Murray)
Date: Fri, 06 Aug 2010 18:26:27 -0400
Subject: [Python-Dev] [python-committers] (Windows) buildbots on 3.x
In-Reply-To: <4C59A933.4070307@v.loewis.de>
References: <AANLkTimK48CRc53_ymurdA+aKo-EDFLM5Nxra5poGWfK@mail.gmail.com>
	<AANLkTi=K55K-Bv6wsfUMs5XYMBcdK50biLTgL74ZuiKw@mail.gmail.com>
	<1280923543.3231.0.camel@localhost.localdomain>
	<AANLkTi=5bxYwuaTDaQ6QXBrxJcW85W+b-nmvqajM3Sor@mail.gmail.com>
	<1280936002.3231.4.camel@localhost.localdomain>
	<4C59A933.4070307@v.loewis.de>
Message-ID: <20100806222627.9BE8521A7BA@kimball.webabinitio.net>

On Wed, 04 Aug 2010 19:53:55 +0200, =?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?= <martin at v.loewis.de> wrote:
> >>> It happens when running test_smtplib before test_smtpb:
> >>
> >> Nice! How did you work that out? I'd like to learn how to diagnose
> >> this sort of thing, because it seems to come up a lot, and I'm not
> >> much use at the moment :-)
> > 
> > I simply tried to run test_smtplib before test_smtpd.
> 
> A more deterministic (and more tedious) way is this: if you
> suspect that some failure might be due to the order of test cases,
> take a build log from the build bot where it fails, and run the tests
> in the exact same order. See whether the problem reproduces.
> 
> If it does, drop tests from the test sequence until you end up with
> the minimum number of tests that you need to run in sequence (and yes,
> I had interworkings of three test modules at some point).
> 
> Of course, educated guessing can accelerate the process.

Two bits of info to help you implement this process:

The buildbots have regrtest print out the random seed used for the
test run.  The --randseed option of regtest can be used to repeat
this run.  That's the first step, which proves that the specific order
produced the test failure.

Then you cut and paste the test list into a file, and use the
regrtest -f option to run the tests from that file, and do
your binary search by breaking up the list into pieces.

Hmm.  If we added a 'binsearch' option to regrtest, you could just
pass it the random seed and that option and off it would go...

--
R. David Murray                                      www.bitdance.com

From ezio.melotti at gmail.com  Sat Aug  7 04:59:31 2010
From: ezio.melotti at gmail.com (Ezio Melotti)
Date: Sat, 07 Aug 2010 05:59:31 +0300
Subject: [Python-Dev] [Python-checkins] r83763 - in
 python/branches/py3k:	Doc/library/signal.rst Lib/test/test_signal.py
 Misc/NEWS	Modules/signalmodule.c
In-Reply-To: <20100806192732.5E323EE9D1@mail.python.org>
References: <20100806192732.5E323EE9D1@mail.python.org>
Message-ID: <4C5CCC13.5070709@gmail.com>

  Hi,

On 06/08/2010 22.27, brian.curtin wrote:
> Author: brian.curtin
> Date: Fri Aug  6 21:27:32 2010
> New Revision: 83763
>
> Log:
> Fix #9324: Add parameter validation to signal.signal on Windows in order
> to prevent crashes.
>
>
> Modified:
>     python/branches/py3k/Doc/library/signal.rst
>     python/branches/py3k/Lib/test/test_signal.py
>     python/branches/py3k/Misc/NEWS
>     python/branches/py3k/Modules/signalmodule.c
>
> Modified: python/branches/py3k/Doc/library/signal.rst
> ==============================================================================
> --- python/branches/py3k/Doc/library/signal.rst	(original)
> +++ python/branches/py3k/Doc/library/signal.rst	Fri Aug  6 21:27:32 2010
> @@ -230,6 +230,10 @@
>      see the :ref:`description in the type hierarchy<frame-objects>` or see the
>      attribute descriptions in the :mod:`inspect` module).
>
> +   On Windows, :func:`signal` can only be called with :const:`SIGABRT`,
> +   :const:`SIGFPE`, :const:`SIGILL`, :const:`SIGINT`, :const:`SIGSEGV`, or
> +   :const:`SIGTERM`. A :exc:`ValueError` will be raised in any other case.
> +
>
>   .. _signal-example:
>
>
> Modified: python/branches/py3k/Lib/test/test_signal.py
> ==============================================================================
> --- python/branches/py3k/Lib/test/test_signal.py	(original)
> +++ python/branches/py3k/Lib/test/test_signal.py	Fri Aug  6 21:27:32 2010
> @@ -9,7 +9,7 @@
>   import traceback
>   import sys, os, time, errno
>
> -if sys.platform[:3] in ('win', 'os2') or sys.platform == 'riscos':
> +if sys.platform == 'os2' or sys.platform == 'riscos':
>       raise unittest.SkipTest("Can't test signal on %s" % \
>                                      sys.platform)
>
> @@ -37,6 +37,7 @@
>           return None
>
>
> + at unittest.skipIf(sys.platform == "win32", "Not valid on Windows")

In the previous chunk sys.platform[:3] was used instead of just 
sys.platform. Are there some other "winXX" platform that should be 
skipped too?

>   class InterProcessSignalTests(unittest.TestCase):
>       MAX_DURATION = 20   # Entire test should last at most 20 sec.
>
> @@ -186,6 +187,7 @@
>                             self.MAX_DURATION)
>
>
> + at unittest.skipIf(sys.platform == "win32", "Not valid on Windows")
>   class BasicSignalTests(unittest.TestCase):
>       def trivial_signal_handler(self, *args):
>           pass
> @@ -208,6 +210,23 @@
>           self.assertEquals(signal.getsignal(signal.SIGHUP), hup)
>
>
> + at unittest.skipUnless(sys.platform == "win32", "Windows specific")
> +class WindowsSignalTests(unittest.TestCase):
> +    def test_issue9324(self):
> +        handler = lambda x, y: None
> +        signal.signal(signal.SIGABRT, handler)
> +        signal.signal(signal.SIGFPE, handler)
> +        signal.signal(signal.SIGILL, handler)
> +        signal.signal(signal.SIGINT, handler)
> +        signal.signal(signal.SIGSEGV, handler)
> +        signal.signal(signal.SIGTERM, handler)
> +
> +        with self.assertRaises(ValueError):
> +            signal.signal(-1, handler)
> +            sinal.signal(7, handler)

You should use two separate assertRaises here, otherwise the second line 
is not executed if the first one raises an error (and if the first 
doesn't raise an error but the second does the test will pass even if it 
shouldn't). This also masks the typo in the second line.

> +
> +
> + at unittest.skipIf(sys.platform == "win32", "Not valid on Windows")
>   class WakeupSignalTests(unittest.TestCase):
>       TIMEOUT_FULL = 10
>       TIMEOUT_HALF = 5
> @@ -253,14 +272,15 @@
>           os.close(self.write)
>           signal.signal(signal.SIGALRM, self.alrm)
>
> + at unittest.skipIf(sys.platform == "win32", "Not valid on Windows")
>   class SiginterruptTest(unittest.TestCase):
> -    signum = signal.SIGUSR1
>
>       def setUp(self):
>           """Install a no-op signal handler that can be set to allow
>           interrupts or not, and arrange for the original signal handler to be
>           re-installed when the test is finished.
>           """
> +        self.signum = signal.SIGUSR1
>           oldhandler = signal.signal(self.signum, lambda x,y: None)
>           self.addCleanup(signal.signal, self.signum, oldhandler)
>
> @@ -354,7 +374,7 @@
>           self.assertFalse(i)
>
>
> -
> + at unittest.skipIf(sys.platform == "win32", "Not valid on Windows")
>   class ItimerTest(unittest.TestCase):
>       def setUp(self):
>           self.hndl_called = False
> @@ -463,8 +483,11 @@
>           self.assertEqual(self.hndl_called, True)
>
>   def test_main():
> -    support.run_unittest(BasicSignalTests, InterProcessSignalTests,
> -        WakeupSignalTests, SiginterruptTest, ItimerTest)
> +    if sys.platform == "win32":
> +        support.run_unittest(WindowsSignalTests)
> +    else:
> +        support.run_unittest(BasicSignalTests, InterProcessSignalTests,
> +            WakeupSignalTests, SiginterruptTest, ItimerTest)

Is this necessary?
If the tests are marked with a skip decorator they will be skipped 
anyway (and also marked as skipped in the output).

>
>
>   if __name__ == "__main__":
>
> Modified: python/branches/py3k/Misc/NEWS
> ==============================================================================
> --- python/branches/py3k/Misc/NEWS	(original)
> +++ python/branches/py3k/Misc/NEWS	Fri Aug  6 21:27:32 2010
> @@ -24,6 +24,9 @@
>   Extensions
>   ----------
>
> +- Issue #9324: Add parameter validation to signal.signal on Windows in order
> +  to prevent crashes.
> +
>   - Issue #9526: Remove some outdated (int) casts that were preventing
>     the array module from working correctly with arrays of more than
>     2**31 elements.
>
> Modified: python/branches/py3k/Modules/signalmodule.c
> ==============================================================================
> --- python/branches/py3k/Modules/signalmodule.c	(original)
> +++ python/branches/py3k/Modules/signalmodule.c	Fri Aug  6 21:27:32 2010
> @@ -255,8 +255,23 @@
>       int sig_num;
>       PyObject *old_handler;
>       void (*func)(int);
> +#ifdef MS_WINDOWS
> +    int cur_sig, num_valid_sigs = 6;
> +    static int valid_sigs[] = {SIGABRT, SIGFPE, SIGILL, SIGINT,
> +                               SIGSEGV, SIGTERM};
> +    BOOL valid_sig = FALSE;
> +#endif
>       if (!PyArg_ParseTuple(args, "iO:signal",&sig_num,&obj))
>           return NULL;
> +#ifdef MS_WINDOWS
> +    /* Validate that sig_num is one of the allowable signals */
> +    for (cur_sig = 0; cur_sig<  num_valid_sigs; cur_sig++)
> +        valid_sig |= (sig_num == valid_sigs[cur_sig]);
> +    if (!valid_sig) {
> +        PyErr_SetString(PyExc_ValueError, "signal number out of range");
> +        return NULL;
> +    }
> +#endif
>   #ifdef WITH_THREAD
>       if (PyThread_get_thread_ident() != main_thread) {
>           PyErr_SetString(PyExc_ValueError,
> _______________________________________________
> Python-checkins mailing list
> Python-checkins at python.org
> http://mail.python.org/mailman/listinfo/python-checkins
>

Best Regards,
Ezio Melotti

From brian.curtin at gmail.com  Sat Aug  7 05:57:43 2010
From: brian.curtin at gmail.com (Brian Curtin)
Date: Fri, 6 Aug 2010 22:57:43 -0500
Subject: [Python-Dev] [Python-checkins] r83763 - in
	python/branches/py3k: Doc/library/signal.rst
	Lib/test/test_signal.py Misc/NEWS Modules/signalmodule.c
In-Reply-To: <4C5CCC13.5070709@gmail.com>
References: <20100806192732.5E323EE9D1@mail.python.org>
	<4C5CCC13.5070709@gmail.com>
Message-ID: <AANLkTimJO2Ro1M514j28txh1y7BX3OoyKzDnW1qwLYDs@mail.gmail.com>

On Fri, Aug 6, 2010 at 21:59, Ezio Melotti <ezio.melotti at gmail.com> wrote:

>  Hi,
>
> On 06/08/2010 22.27, brian.curtin wrote:
>
>> Author: brian.curtin
>> Date: Fri Aug  6 21:27:32 2010
>> New Revision: 83763
>>
>> Log:
>> Fix #9324: Add parameter validation to signal.signal on Windows in order
>> to prevent crashes.
>>
>>
>> Modified:
>>    python/branches/py3k/Doc/library/signal.rst
>>    python/branches/py3k/Lib/test/test_signal.py
>>    python/branches/py3k/Misc/NEWS
>>    python/branches/py3k/Modules/signalmodule.c
>>
>> Modified: python/branches/py3k/Doc/library/signal.rst
>>
>> ==============================================================================
>> --- python/branches/py3k/Doc/library/signal.rst (original)
>> +++ python/branches/py3k/Doc/library/signal.rst Fri Aug  6 21:27:32 2010
>> @@ -230,6 +230,10 @@
>>     see the :ref:`description in the type hierarchy<frame-objects>` or see
>> the
>>     attribute descriptions in the :mod:`inspect` module).
>>
>> +   On Windows, :func:`signal` can only be called with :const:`SIGABRT`,
>> +   :const:`SIGFPE`, :const:`SIGILL`, :const:`SIGINT`, :const:`SIGSEGV`,
>> or
>> +   :const:`SIGTERM`. A :exc:`ValueError` will be raised in any other
>> case.
>> +
>>
>>  .. _signal-example:
>>
>>
>> Modified: python/branches/py3k/Lib/test/test_signal.py
>>
>> ==============================================================================
>> --- python/branches/py3k/Lib/test/test_signal.py        (original)
>> +++ python/branches/py3k/Lib/test/test_signal.py        Fri Aug  6
>> 21:27:32 2010
>> @@ -9,7 +9,7 @@
>>  import traceback
>>  import sys, os, time, errno
>>
>> -if sys.platform[:3] in ('win', 'os2') or sys.platform == 'riscos':
>> +if sys.platform == 'os2' or sys.platform == 'riscos':
>>      raise unittest.SkipTest("Can't test signal on %s" % \
>>                                     sys.platform)
>>
>> @@ -37,6 +37,7 @@
>>          return None
>>
>>
>> + at unittest.skipIf(sys.platform == "win32", "Not valid on Windows")
>>
>
> In the previous chunk sys.platform[:3] was used instead of just
> sys.platform. Are there some other "winXX" platform that should be skipped
> too?
>

The sliced check was to make it more convenient to also check "os2" at the
same time in the first hunk of the change. Windows is "win32" regardless of
32 or 64-bit so that check works.

  class InterProcessSignalTests(unittest.TestCase):
>>      MAX_DURATION = 20   # Entire test should last at most 20 sec.
>>
>> @@ -186,6 +187,7 @@
>>                            self.MAX_DURATION)
>>
>>
>> + at unittest.skipIf(sys.platform == "win32", "Not valid on Windows")
>>  class BasicSignalTests(unittest.TestCase):
>>      def trivial_signal_handler(self, *args):
>>          pass
>> @@ -208,6 +210,23 @@
>>          self.assertEquals(signal.getsignal(signal.SIGHUP), hup)
>>
>>
>> + at unittest.skipUnless(sys.platform == "win32", "Windows specific")
>> +class WindowsSignalTests(unittest.TestCase):
>> +    def test_issue9324(self):
>> +        handler = lambda x, y: None
>> +        signal.signal(signal.SIGABRT, handler)
>> +        signal.signal(signal.SIGFPE, handler)
>> +        signal.signal(signal.SIGILL, handler)
>> +        signal.signal(signal.SIGINT, handler)
>> +        signal.signal(signal.SIGSEGV, handler)
>> +        signal.signal(signal.SIGTERM, handler)
>> +
>> +        with self.assertRaises(ValueError):
>> +            signal.signal(-1, handler)
>> +            sinal.signal(7, handler)
>>
>
> You should use two separate assertRaises here, otherwise the second line is
> not executed if the first one raises an error (and if the first doesn't
> raise an error but the second does the test will pass even if it shouldn't).
> This also masks the typo in the second line.
>

Thanks for noticing this. Corrected in r83771 (py3k), r83772
(release31-maint), and r83773 (release27-maint).

 +
>> +
>> + at unittest.skipIf(sys.platform == "win32", "Not valid on Windows")
>>  class WakeupSignalTests(unittest.TestCase):
>>      TIMEOUT_FULL = 10
>>      TIMEOUT_HALF = 5
>> @@ -253,14 +272,15 @@
>>          os.close(self.write)
>>          signal.signal(signal.SIGALRM, self.alrm)
>>
>> + at unittest.skipIf(sys.platform == "win32", "Not valid on Windows")
>>  class SiginterruptTest(unittest.TestCase):
>> -    signum = signal.SIGUSR1
>>
>>      def setUp(self):
>>          """Install a no-op signal handler that can be set to allow
>>          interrupts or not, and arrange for the original signal handler to
>> be
>>          re-installed when the test is finished.
>>          """
>> +        self.signum = signal.SIGUSR1
>>          oldhandler = signal.signal(self.signum, lambda x,y: None)
>>          self.addCleanup(signal.signal, self.signum, oldhandler)
>>
>> @@ -354,7 +374,7 @@
>>          self.assertFalse(i)
>>
>>
>> -
>> + at unittest.skipIf(sys.platform == "win32", "Not valid on Windows")
>>  class ItimerTest(unittest.TestCase):
>>      def setUp(self):
>>          self.hndl_called = False
>> @@ -463,8 +483,11 @@
>>          self.assertEqual(self.hndl_called, True)
>>
>>  def test_main():
>> -    support.run_unittest(BasicSignalTests, InterProcessSignalTests,
>> -        WakeupSignalTests, SiginterruptTest, ItimerTest)
>> +    if sys.platform == "win32":
>> +        support.run_unittest(WindowsSignalTests)
>> +    else:
>> +        support.run_unittest(BasicSignalTests, InterProcessSignalTests,
>> +            WakeupSignalTests, SiginterruptTest, ItimerTest)
>>
>
> Is this necessary?
> If the tests are marked with a skip decorator they will be skipped anyway
> (and also marked as skipped in the output).
>

Good point. Fixed in the above revisions.

 if __name__ == "__main__":
>>
>> Modified: python/branches/py3k/Misc/NEWS
>>
>> ==============================================================================
>> --- python/branches/py3k/Misc/NEWS      (original)
>> +++ python/branches/py3k/Misc/NEWS      Fri Aug  6 21:27:32 2010
>> @@ -24,6 +24,9 @@
>>  Extensions
>>  ----------
>>
>> +- Issue #9324: Add parameter validation to signal.signal on Windows in
>> order
>> +  to prevent crashes.
>> +
>>  - Issue #9526: Remove some outdated (int) casts that were preventing
>>    the array module from working correctly with arrays of more than
>>    2**31 elements.
>>
>> Modified: python/branches/py3k/Modules/signalmodule.c
>>
>> ==============================================================================
>> --- python/branches/py3k/Modules/signalmodule.c (original)
>> +++ python/branches/py3k/Modules/signalmodule.c Fri Aug  6 21:27:32 2010
>> @@ -255,8 +255,23 @@
>>      int sig_num;
>>      PyObject *old_handler;
>>      void (*func)(int);
>> +#ifdef MS_WINDOWS
>> +    int cur_sig, num_valid_sigs = 6;
>> +    static int valid_sigs[] = {SIGABRT, SIGFPE, SIGILL, SIGINT,
>> +                               SIGSEGV, SIGTERM};
>> +    BOOL valid_sig = FALSE;
>> +#endif
>>      if (!PyArg_ParseTuple(args, "iO:signal",&sig_num,&obj))
>>          return NULL;
>> +#ifdef MS_WINDOWS
>> +    /* Validate that sig_num is one of the allowable signals */
>> +    for (cur_sig = 0; cur_sig<  num_valid_sigs; cur_sig++)
>> +        valid_sig |= (sig_num == valid_sigs[cur_sig]);
>> +    if (!valid_sig) {
>> +        PyErr_SetString(PyExc_ValueError, "signal number out of range");
>> +        return NULL;
>> +    }
>> +#endif
>>  #ifdef WITH_THREAD
>>      if (PyThread_get_thread_ident() != main_thread) {
>>          PyErr_SetString(PyExc_ValueError,
>>
>
> Best Regards,
> Ezio Melotti
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100806/f12be380/attachment.html>

From ocean-city at m2.ccsnet.ne.jp  Sat Aug  7 10:24:01 2010
From: ocean-city at m2.ccsnet.ne.jp (Hirokazu Yamamoto)
Date: Sat, 07 Aug 2010 17:24:01 +0900
Subject: [Python-Dev] [Python-checkins] r83763 - in
 python/branches/py3k:	Doc/library/signal.rst Lib/test/test_signal.py
 Misc/NEWS	Modules/signalmodule.c
In-Reply-To: <20100806192732.5E323EE9D1@mail.python.org>
References: <20100806192732.5E323EE9D1@mail.python.org>
Message-ID: <4C5D1821.8070004@m2.ccsnet.ne.jp>

This is the idea just popped up. :-)

#define SIG(name) if (sig_num != SIG##name)
     SIG(ABRT) SIG(FPE) SIG(ILL) SIG(INT) SIG(SEGV) SIG(TERM) {
          PyErr_SetString(PyExc_ValueError, "signal number out of range");
          return NULL;
      }
#undef SIG


From ocean-city at m2.ccsnet.ne.jp  Sat Aug  7 10:07:01 2010
From: ocean-city at m2.ccsnet.ne.jp (Hirokazu Yamamoto)
Date: Sat, 07 Aug 2010 17:07:01 +0900
Subject: [Python-Dev] [Python-checkins] r83763 - in
 python/branches/py3k:	Doc/library/signal.rst Lib/test/test_signal.py
 Misc/NEWS	Modules/signalmodule.c
In-Reply-To: <20100806192732.5E323EE9D1@mail.python.org>
References: <20100806192732.5E323EE9D1@mail.python.org>
Message-ID: <4C5D1425.2070802@m2.ccsnet.ne.jp>

> +        valid_sig |= (sig_num == valid_sigs[cur_sig]);

I think ||= is more appropriate here.

From kristjan at ccpgames.com  Sat Aug  7 11:59:21 2010
From: kristjan at ccpgames.com (=?iso-8859-1?Q?Kristj=E1n_Valur_J=F3nsson?=)
Date: Sat, 7 Aug 2010 09:59:21 +0000
Subject: [Python-Dev] builtin round 2.7
Message-ID: <930F189C8A437347B80DF2C156F7EC7F0B8DCE8FF6@exchis.ccp.ad.local>

Hi there.
I just hit a problem in my company, in the process of upgrading from stackless 2.5 to 2.7.
Some rounding code, that was (foolishly) using "%.*f" string formatting to achieve floating point rounding started providing different results from before.  I explained this away to QA and Developement as a) you shouldn't do that, and b) string representation of floats became better and "more correct" in 2.7.  For UI rounding, I directed them to the Decimal module.

So far so good.

But it appears that the builtin round() method also changed.  Whereas I see the changing of floating point representation in string formatting as not being very serious, why did the arithmetic function round() have to change?  I don't see this mentioned in the release notes and was initially a bit puzzled by it.  Hasn't anyone else been hit by the discrepancy?

(and, yes, I know it is now more correct, as seen by round(5.55, 1)  (5.6 in py2.5, 5.5 in py 2.7 which is correct since 5.55 is actually 5.549999... )

Perhaps the release notes need updating?

K


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100807/9623e6f8/attachment.html>

From greg.ewing at canterbury.ac.nz  Sat Aug  7 12:09:16 2010
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sat, 07 Aug 2010 22:09:16 +1200
Subject: [Python-Dev] [Python-checkins] r83763 - in
 python/branches/py3k: Doc/library/signal.rst Lib/test/test_signal.py
 Misc/NEWS	Modules/signalmodule.c
In-Reply-To: <4C5D1821.8070004@m2.ccsnet.ne.jp>
References: <20100806192732.5E323EE9D1@mail.python.org>
	<4C5D1821.8070004@m2.ccsnet.ne.jp>
Message-ID: <4C5D30CC.5080908@canterbury.ac.nz>

Hirokazu Yamamoto wrote:

> #define SIG(name) if (sig_num != SIG##name)
>     SIG(ABRT) SIG(FPE) SIG(ILL) SIG(INT) SIG(SEGV) SIG(TERM) {
>          PyErr_SetString(PyExc_ValueError, "signal number out of range");

"Out of range" doesn't seem like quite the right message here,
because it suggests a contiguous range of legal values, which
isn't the case.

-- 
Greg

From ronaldoussoren at mac.com  Sat Aug  7 12:18:55 2010
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Sat, 07 Aug 2010 12:18:55 +0200
Subject: [Python-Dev] [Python-checkins] r83763 - in
 python/branches/py3k: Doc/library/signal.rst Lib/test/test_signal.py
 Misc/NEWS	Modules/signalmodule.c
In-Reply-To: <4C5D1821.8070004@m2.ccsnet.ne.jp>
References: <20100806192732.5E323EE9D1@mail.python.org>
	<4C5D1821.8070004@m2.ccsnet.ne.jp>
Message-ID: <414C2140-1520-48AB-80FD-EDE17058B3CB@mac.com>


On 7 Aug, 2010, at 10:24, Hirokazu Yamamoto wrote:

> This is the idea just popped up. :-)
> 
> #define SIG(name) if (sig_num != SIG##name)
>    SIG(ABRT) SIG(FPE) SIG(ILL) SIG(INT) SIG(SEGV) SIG(TERM) {
>         PyErr_SetString(PyExc_ValueError, "signal number out of range");
>         return NULL;
>     }
> #undef SIG

What's wrong with:

switch (sig_num) {
case SIGABRT: 
case SIGFPE:
...
case SIGTERM:
       break;
default:
      PyErr_SetString(...)
      return NULL;
}

That would IMO be clearer than the macro you propose.

Ronald
> 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/ronaldoussoren%40mac.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3567 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100807/bf594fd9/attachment.bin>

From p.f.moore at gmail.com  Sat Aug  7 12:34:51 2010
From: p.f.moore at gmail.com (Paul Moore)
Date: Sat, 7 Aug 2010 11:34:51 +0100
Subject: [Python-Dev] [Python-checkins] r83763 - in
	python/branches/py3k: Doc/library/signal.rst
	Lib/test/test_signal.py Misc/NEWS Modules/signalmodule.c
In-Reply-To: <AANLkTimJO2Ro1M514j28txh1y7BX3OoyKzDnW1qwLYDs@mail.gmail.com>
References: <20100806192732.5E323EE9D1@mail.python.org>
	<4C5CCC13.5070709@gmail.com>
	<AANLkTimJO2Ro1M514j28txh1y7BX3OoyKzDnW1qwLYDs@mail.gmail.com>
Message-ID: <AANLkTimQD=mpFr6Jy3SVgywnX2qKdXbQYthF4yR=8DhT@mail.gmail.com>

On 7 August 2010 04:57, Brian Curtin <brian.curtin at gmail.com> wrote:
>>> -if sys.platform[:3] in ('win', 'os2') or sys.platform == 'riscos':

> The sliced check was to make it more convenient to also check "os2" at the
> same time in the first hunk of the change. Windows is "win32" regardless of
> 32 or 64-bit so that check works.

Wouldn't

if sys.platform in ('win32', 'os2', 'riscos'):

work just as well?

Paul

From dickinsm at gmail.com  Sat Aug  7 12:58:39 2010
From: dickinsm at gmail.com (Mark Dickinson)
Date: Sat, 7 Aug 2010 11:58:39 +0100
Subject: [Python-Dev] builtin round 2.7
In-Reply-To: <930F189C8A437347B80DF2C156F7EC7F0B8DCE8FF6@exchis.ccp.ad.local>
References: <930F189C8A437347B80DF2C156F7EC7F0B8DCE8FF6@exchis.ccp.ad.local>
Message-ID: <AANLkTimk=htNin=KVYKpTdPPRtFib8FmxdHoPStjKyUB@mail.gmail.com>

2010/8/7 Kristj?n Valur J?nsson <kristjan at ccpgames.com>:
> Hi there.
> [...]
> But it appears that the builtin round() method also changed.? Whereas I see
> the changing of floating point representation in string formatting as not
> being very serious, why did the arithmetic function round() have to change?

This was part of the short float repr changes that were backported
from 3.1.  The round function in 2.7 (on most platforms; barring bugs)
always gives correctly rounded results; in 2.6 it was a bit less
predictable in halfway cases.

One reason to want round to be correctly rounded is to ensure that the
repr of the result is always the 'short' one;  this means that
repr(round(x, 2)) will never produce results like
'0.23000000000000001'.  If the round function hadn't been updated to
be correctly rounded then this wouldn't be true.

Another reason is to make sure that string formatting and the round
function finally agree with each other:  both are doing the same job
of rounding to some nearest decimal representation (except that one
returns a float, while the other returns a string), so the results
should be comparable;  the discrepancy between these two operations
has confused users in the past.  Unfortunately, the agreement isn't
quite complete, since round in 2.7 continues to use
round-half-away-from-zero for actual exact halfway cases, while string
formatting uses round-half-to-even (so e.g. round(0.125, 2) gives (a
binary approximation to) 0.13, while format(0.125, '.2f') gives
'0.12').  In 3.x they both use round-half-to-even.

The only place where people are likely to notice that the round result
has changed is in halfway cases, for example round(12.385, 2) (which,
of course, thanks to the usual binary floating-point issues, is only
actually an approximation to a halfway case).  In general, if you're
expecting predictable results from *decimal* rounding of *binary*
approximations to *decimal* halfway cases then you're asking for
trouble.  For predictable rounding, use the decimal module.

I recently added some text to the floating-point section of the 2.7
tutorial to help explain these round problems.

> I don?t see this mentioned in the release notes and was initially a bit
> puzzled by it.

True;  I don't see it in the whatsnew document either.  It's in
Misc/NEWS, though.  (Search for Issue 7117;  there are several
entries).

Mark

From ezio.melotti at gmail.com  Sat Aug  7 14:49:05 2010
From: ezio.melotti at gmail.com (Ezio Melotti)
Date: Sat, 07 Aug 2010 15:49:05 +0300
Subject: [Python-Dev] [Python-checkins] r83778 - in
 python/branches/py3k/Lib/test: test_import.py test_sax.py test_sys.py
 test_urllib.py	test_urllib2.py test_xml_etree.py
In-Reply-To: <20100807100935.4C911EEA3B@mail.python.org>
References: <20100807100935.4C911EEA3B@mail.python.org>
Message-ID: <4C5D5641.4040509@gmail.com>

  Hi,

On 07/08/2010 13.09, victor.stinner wrote:
> Author: victor.stinner
> Date: Sat Aug  7 12:09:35 2010
> New Revision: 83778
>
> Log:
> Issue #9425: skip tests if a filename is not encodable
>
> Modified:
>     python/branches/py3k/Lib/test/test_import.py
>     python/branches/py3k/Lib/test/test_sax.py
>     python/branches/py3k/Lib/test/test_sys.py
>     python/branches/py3k/Lib/test/test_urllib.py
>     python/branches/py3k/Lib/test/test_urllib2.py
>     python/branches/py3k/Lib/test/test_xml_etree.py
>
> Modified: python/branches/py3k/Lib/test/test_import.py
> ==============================================================================
> --- python/branches/py3k/Lib/test/test_import.py	(original)
> +++ python/branches/py3k/Lib/test/test_import.py	Sat Aug  7 12:09:35 2010
> @@ -291,6 +291,11 @@
>
>       def test_import_by_filename(self):
>           path = os.path.abspath(TESTFN)
> +        encoding = sys.getfilesystemencoding()
> +        try:
> +            path.encode(encoding)
> +        except UnicodeEncodeError:
> +            self.skipTest('path is not encodable to {}'.format(encoding))
>           with self.assertRaises(ImportError) as c:
>               __import__(path)
>           self.assertEqual("Import by filename is not supported.",
>
> Modified: python/branches/py3k/Lib/test/test_sax.py
> ==============================================================================
> --- python/branches/py3k/Lib/test/test_sax.py	(original)
> +++ python/branches/py3k/Lib/test/test_sax.py	Sat Aug  7 12:09:35 2010
> @@ -18,6 +18,11 @@
>
>   TEST_XMLFILE = findfile("test.xml", subdir="xmltestdata")
>   TEST_XMLFILE_OUT = findfile("test.xml.out", subdir="xmltestdata")
> +try:
> +    TEST_XMLFILE.encode("utf8")
> +    TEST_XMLFILE_OUT.encode("utf8")
> +except UnicodeEncodeError:
> +    raise unittest.SkipTest("filename is not encodable to utf8")
>
>   ns_uri = "http://www.python.org/xml-ns/saxtest/"
>
>
> Modified: python/branches/py3k/Lib/test/test_sys.py
> ==============================================================================
> --- python/branches/py3k/Lib/test/test_sys.py	(original)
> +++ python/branches/py3k/Lib/test/test_sys.py	Sat Aug  7 12:09:35 2010
> @@ -509,8 +509,10 @@
>           p = subprocess.Popen([sys.executable, "-c", code], stderr=subprocess.PIPE)
>           stdout, stderr = p.communicate()
>           self.assertEqual(p.returncode, 1)
> -        self.assert_(b"UnicodeEncodeError:" in stderr,
> -            "%r not in %s" % (b"UniodeEncodeError:", ascii(stderr)))
> +        self.assertIn(
> +            br"UnicodeEncodeError: 'utf-8' codec can't encode character "
> +            br"'\udcff' in position 7: surrogates not allowed",
> +            stderr)

This caused some failures in the buildbots:

test test_sys failed -- Traceback (most recent call last):
   File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/test/test_sys.py", line 515, in test_main_invalid_unicode
     stderr)
AssertionError:
b"UnicodeEncodeError: 'utf-8' codec can't encode character '\\udcff' in position 7: surrogates not allowed" not found in
b'Traceback (most recent call last):\n  File "<string>", line 1, in<module>\nUnicodeEncodeError: \'ascii\' codec can\'t encode character \'\\xff\' in position 0: ordinal not in range(128)\n[32513 refs]\n'


See http://www.python.org/dev/buildbot/all/builders/sparc%20solaris10%20gcc%203.x/builds/1338/steps/test/logs/stdio


>
>       def test_sys_flags(self):
>           self.assertTrue(sys.flags)
>
> Modified: python/branches/py3k/Lib/test/test_urllib.py
> ==============================================================================
> --- python/branches/py3k/Lib/test/test_urllib.py	(original)
> +++ python/branches/py3k/Lib/test/test_urllib.py	Sat Aug  7 12:09:35 2010
> @@ -232,8 +232,12 @@
>               except: pass
>
>       def constructLocalFileUrl(self, filePath):
> -        return "file://%s" % urllib.request.pathname2url(
> -            os.path.abspath(filePath))
> +        filePath = os.path.abspath(filePath)
> +        try:
> +            filePath.encode("utf8")
> +        except UnicodeEncodeError:
> +            raise unittest.SkipTest("filePath is not encodable to utf8")
> +        return "file://%s" % urllib.request.pathname2url(filePath)
>
>       def createNewTempFile(self, data=b""):
>           """Creates a new temporary file containing the specified data,
>
> Modified: python/branches/py3k/Lib/test/test_urllib2.py
> ==============================================================================
> --- python/branches/py3k/Lib/test/test_urllib2.py	(original)
> +++ python/branches/py3k/Lib/test/test_urllib2.py	Sat Aug  7 12:09:35 2010
> @@ -597,6 +597,10 @@
>
>
>   def sanepathname2url(path):
> +    try:
> +        path.encode("utf8")
> +    except UnicodeEncodeError:
> +        raise unittest.SkipTest("path is not encodable to utf8")
>       urlpath = urllib.request.pathname2url(path)
>       if os.name == "nt" and urlpath.startswith("///"):
>           urlpath = urlpath[2:]
>
> Modified: python/branches/py3k/Lib/test/test_xml_etree.py
> ==============================================================================
> --- python/branches/py3k/Lib/test/test_xml_etree.py	(original)
> +++ python/branches/py3k/Lib/test/test_xml_etree.py	Sat Aug  7 12:09:35 2010
> @@ -13,6 +13,7 @@
>
>   import sys
>   import cgi
> +import unittest
>
>   from test import support
>   from test.support import findfile
> @@ -20,6 +21,10 @@
>   from xml.etree import ElementTree as ET
>
>   SIMPLE_XMLFILE = findfile("simple.xml", subdir="xmltestdata")
> +try:
> +    SIMPLE_XMLFILE.encode("utf8")
> +except UnicodeEncodeError:
> +    raise unittest.SkipTest("filename is not encodable to utf8")
>   SIMPLE_NS_XMLFILE = findfile("simple-ns.xml", subdir="xmltestdata")
>
>   SAMPLE_XML = """\
> _______________________________________________
> Python-checkins mailing list
> Python-checkins at python.org
> http://mail.python.org/mailman/listinfo/python-checkins
>

Best Regards,
Ezio Melotti

From ocean-city at m2.ccsnet.ne.jp  Sat Aug  7 15:20:25 2010
From: ocean-city at m2.ccsnet.ne.jp (Hirokazu Yamamoto)
Date: Sat, 07 Aug 2010 22:20:25 +0900
Subject: [Python-Dev] [Python-checkins] r83763 - in
 python/branches/py3k: Doc/library/signal.rst Lib/test/test_signal.py
 Misc/NEWS	Modules/signalmodule.c
In-Reply-To: <4C5D30CC.5080908@canterbury.ac.nz>
References: <20100806192732.5E323EE9D1@mail.python.org>	<4C5D1821.8070004@m2.ccsnet.ne.jp>
	<4C5D30CC.5080908@canterbury.ac.nz>
Message-ID: <4C5D5D99.6060809@m2.ccsnet.ne.jp>

On 2010/08/07 19:09, Greg Ewing wrote:
> Hirokazu Yamamoto wrote:
>
>> #define SIG(name) if (sig_num != SIG##name)
>> SIG(ABRT) SIG(FPE) SIG(ILL) SIG(INT) SIG(SEGV) SIG(TERM) {
>> PyErr_SetString(PyExc_ValueError, "signal number out of range");
>
> "Out of range" doesn't seem like quite the right message here,
> because it suggests a contiguous range of legal values, which
> isn't the case.

I agree, I suppose "invalid signal number" or something is better.

From ocean-city at m2.ccsnet.ne.jp  Sat Aug  7 15:21:54 2010
From: ocean-city at m2.ccsnet.ne.jp (Hirokazu Yamamoto)
Date: Sat, 07 Aug 2010 22:21:54 +0900
Subject: [Python-Dev] [Python-checkins] r83763 - in
 python/branches/py3k: Doc/library/signal.rst Lib/test/test_signal.py
 Misc/NEWS	Modules/signalmodule.c
In-Reply-To: <414C2140-1520-48AB-80FD-EDE17058B3CB@mac.com>
References: <20100806192732.5E323EE9D1@mail.python.org>
	<4C5D1821.8070004@m2.ccsnet.ne.jp>
	<414C2140-1520-48AB-80FD-EDE17058B3CB@mac.com>
Message-ID: <4C5D5DF2.3080901@m2.ccsnet.ne.jp>

On 2010/08/07 19:18, Ronald Oussoren wrote:
>
> On 7 Aug, 2010, at 10:24, Hirokazu Yamamoto wrote:
>
>> This is the idea just popped up. :-)
>>
>> #define SIG(name) if (sig_num != SIG##name)
>>     SIG(ABRT) SIG(FPE) SIG(ILL) SIG(INT) SIG(SEGV) SIG(TERM) {
>>          PyErr_SetString(PyExc_ValueError, "signal number out of range");
>>          return NULL;
>>      }
>> #undef SIG
>
> What's wrong with:
>
> switch (sig_num) {
> case SIGABRT:
> case SIGFPE:
> ...
> case SIGTERM:
>         break;
> default:
>        PyErr_SetString(...)
>        return NULL;
> }
>
> That would IMO be clearer than the macro you propose.
>
> Ronald

Hmm... I liked the macro idea, but nothing is wrong with switch
statement.


From brian.curtin at gmail.com  Sat Aug  7 16:42:31 2010
From: brian.curtin at gmail.com (Brian Curtin)
Date: Sat, 7 Aug 2010 09:42:31 -0500
Subject: [Python-Dev] [Python-checkins] r83763 - in
	python/branches/py3k: Doc/library/signal.rst
	Lib/test/test_signal.py Misc/NEWS Modules/signalmodule.c
In-Reply-To: <4C5D5DF2.3080901@m2.ccsnet.ne.jp>
References: <20100806192732.5E323EE9D1@mail.python.org>
	<4C5D1821.8070004@m2.ccsnet.ne.jp>
	<414C2140-1520-48AB-80FD-EDE17058B3CB@mac.com>
	<4C5D5DF2.3080901@m2.ccsnet.ne.jp>
Message-ID: <AANLkTikL-N-DauTgjCDcqBVQ8gz9buSTxcUEY5UGe_Xe@mail.gmail.com>

On Sat, Aug 7, 2010 at 08:21, Hirokazu Yamamoto
<ocean-city at m2.ccsnet.ne.jp>wrote:

> On 2010/08/07 19:18, Ronald Oussoren wrote:
>
>>
>> On 7 Aug, 2010, at 10:24, Hirokazu Yamamoto wrote:
>>
>>  This is the idea just popped up. :-)
>>>
>>> #define SIG(name) if (sig_num != SIG##name)
>>>    SIG(ABRT) SIG(FPE) SIG(ILL) SIG(INT) SIG(SEGV) SIG(TERM) {
>>>         PyErr_SetString(PyExc_ValueError, "signal number out of range");
>>>         return NULL;
>>>     }
>>> #undef SIG
>>>
>>
>> What's wrong with:
>>
>> switch (sig_num) {
>> case SIGABRT:
>> case SIGFPE:
>> ...
>> case SIGTERM:
>>        break;
>> default:
>>       PyErr_SetString(...)
>>       return NULL;
>> }
>>
>> That would IMO be clearer than the macro you propose.
>>
>> Ronald
>>
>
> Hmm... I liked the macro idea, but nothing is wrong with switch
> statement.


I had thought about doing this via switch statement. I'll propose a patch
and post it on #9324.

As for the "out of range" comment -- true, it's not technically a range on
Windows, but it matches the exception wording when we raise on Mac/Linux for
the same reason. I can change that.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100807/85bfbebc/attachment-0001.html>

From linux at gabriel-striewe.de  Sat Aug  7 21:55:41 2010
From: linux at gabriel-striewe.de (linux at gabriel-striewe.de)
Date: Sat, 7 Aug 2010 21:55:41 +0200
Subject: [Python-Dev] mingw support?
Message-ID: <20100807195541.GA13990@laptop.gs>

Dear list,

I was wondering whether there would ever be support for python to be
build by the mingw compiler suite. I found a few patches in the
internet but there were disagreeing comments on whether they are
functional or not. 

So I would like to ask the list whether there are any technical
reasons that this is so. I did a search on the python site for mingw,
but all I found are explanations how to compile python modules, but
not python itself. 

I know the question is why anybody should want to do so, but I do
think that a project which depends on a non-free compiler is not free
after all.

Regards,

Gabriel 

From steve at holdenweb.com  Sat Aug  7 22:14:11 2010
From: steve at holdenweb.com (Steve Holden)
Date: Sat, 07 Aug 2010 16:14:11 -0400
Subject: [Python-Dev] mingw support?
In-Reply-To: <20100807195541.GA13990@laptop.gs>
References: <20100807195541.GA13990@laptop.gs>
Message-ID: <i3keql$fsu$1@dough.gmane.org>

On 8/7/2010 3:55 PM, linux at gabriel-striewe.de wrote:
> Dear list,
> 
> I was wondering whether there would ever be support for python to be
> build by the mingw compiler suite. I found a few patches in the
> internet but there were disagreeing comments on whether they are
> functional or not. 
> 
> So I would like to ask the list whether there are any technical
> reasons that this is so. I did a search on the python site for mingw,
> but all I found are explanations how to compile python modules, but
> not python itself. 
> 
> I know the question is why anybody should want to do so, but I do
> think that a project which depends on a non-free compiler is not free
> after all.
> 
There have certainly been demonstrations that Python can be compiled
with mingw, but as far as I am aware what's  missing is a developer
sufficiently motivated to integrate that build system into the
distributions and maintain it.

regards
 Steve
-- 
Steve Holden           +1 571 484 6266   +1 800 494 3119
DjangoCon US September 7-9, 2010    http://djangocon.us/
See Python Video!       http://python.mirocommunity.org/
Holden Web LLC                 http://www.holdenweb.com/


From dickinsm at gmail.com  Sat Aug  7 23:43:50 2010
From: dickinsm at gmail.com (Mark Dickinson)
Date: Sat, 7 Aug 2010 22:43:50 +0100
Subject: [Python-Dev] builtin round 2.7
In-Reply-To: <AANLkTimk=htNin=KVYKpTdPPRtFib8FmxdHoPStjKyUB@mail.gmail.com>
References: <930F189C8A437347B80DF2C156F7EC7F0B8DCE8FF6@exchis.ccp.ad.local>
	<AANLkTimk=htNin=KVYKpTdPPRtFib8FmxdHoPStjKyUB@mail.gmail.com>
Message-ID: <AANLkTinqnaVE7c_AR9vcTbG_LPC4BgSvtNwX4=kSrGZU@mail.gmail.com>

2010/8/7 Mark Dickinson <dickinsm at gmail.com>:
> 2010/8/7 Kristj?n Valur J?nsson <kristjan at ccpgames.com>:
>> Hi there.
>> [...]
>> But it appears that the builtin round() method also changed.? Whereas I see
>> the changing of floating point representation in string formatting as not
>> being very serious, why did the arithmetic function round() have to change?
>
> One reason to want round to be correctly rounded is to ensure that the
> repr of the result is always the 'short' one; ?this means that
> repr(round(x, 2)) will never produce results like
> '0.23000000000000001'. ?If the round function hadn't been updated to
> be correctly rounded then this wouldn't be true.
> [...]

I should also point out that the pre-2.7 round function isn't
consistent across common platforms, so it was already dangerous to
rely on round results for halfway cases;  the 2.7 version of round
should be an improvement in that respect.  For example, with Python
2.6.6rc1 on OS X 10.6.4, I get the (correct) result:

>>> round(1.0007605, 6)
1.0007600000000001

I'd expect to see the same result on OS X 10.5, on Windows and on
64-bit Linux boxes.  But on a 32-bit installation of Ubuntu maverick
(32-bit), I get the following instead:

>>> round(1.0007605, 6)
1.000761

The discrepancy is due to the usual problem of the x87 FPU computing
internally with 64-bit precision and then rounding the result to
53-bit precision afterwards, which can give different results from
computing directly using 53-bit precision.

Mark

From ncoghlan at gmail.com  Sun Aug  8 02:12:07 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 8 Aug 2010 10:12:07 +1000
Subject: [Python-Dev] mingw support?
In-Reply-To: <20100807195541.GA13990@laptop.gs>
References: <20100807195541.GA13990@laptop.gs>
Message-ID: <AANLkTim+WHSzUgS8HLnQbSaK=kYjUUNKArdxiSsnycFz@mail.gmail.com>

On Sun, Aug 8, 2010 at 5:55 AM,  <linux at gabriel-striewe.de> wrote:
> I know the question is why anybody should want to do so, but I do
> think that a project which depends on a non-free compiler is not free
> after all.

It's a philosophical question - Python is under a BSD style license,
so the core devs (taken as a group) don't have a fundamental objection
to the idea of closed source software, just a pragmatic view that open
source is simply a better approach most of the time (both as a
developer and as a user).

This used to be more of an issue because MS didn't provide a decent
free compiler for their platform. These days (since the release of
Visual Studio Express), we expect that people willing to use (or
support) a closed OS can cope with also using the free-as-in-beer
closed compiler provided by the vendor of that OS.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From martin at v.loewis.de  Sun Aug  8 02:54:20 2010
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 08 Aug 2010 02:54:20 +0200
Subject: [Python-Dev] mingw support?
In-Reply-To: <AANLkTim+WHSzUgS8HLnQbSaK=kYjUUNKArdxiSsnycFz@mail.gmail.com>
References: <20100807195541.GA13990@laptop.gs>
	<AANLkTim+WHSzUgS8HLnQbSaK=kYjUUNKArdxiSsnycFz@mail.gmail.com>
Message-ID: <4C5E003C.9030807@v.loewis.de>

Am 08.08.2010 02:12, schrieb Nick Coghlan:
> On Sun, Aug 8, 2010 at 5:55 AM,  <linux at gabriel-striewe.de> wrote:
>> I know the question is why anybody should want to do so, but I do
>> think that a project which depends on a non-free compiler is not free
>> after all.
> 
> It's a philosophical question

It's also a technical question. Supporting mingw on an ongoing basis is
fairly difficult, for various reasons. There would be nothing inherently
wrong with supporting mingw - it's just that none of the committers has
found enough time and motivation to work on this (either using one of
the contributed patches, or starting from scratch).

Regards,
Martin

From greg.ewing at canterbury.ac.nz  Sun Aug  8 03:27:23 2010
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sun, 08 Aug 2010 13:27:23 +1200
Subject: [Python-Dev] mingw support?
In-Reply-To: <AANLkTim+WHSzUgS8HLnQbSaK=kYjUUNKArdxiSsnycFz@mail.gmail.com>
References: <20100807195541.GA13990@laptop.gs>
	<AANLkTim+WHSzUgS8HLnQbSaK=kYjUUNKArdxiSsnycFz@mail.gmail.com>
Message-ID: <4C5E07FB.8070203@canterbury.ac.nz>

Nick Coghlan wrote:

> This used to be more of an issue because MS didn't provide a decent
> free compiler for their platform. These days (since the release of
> Visual Studio Express), we expect that people willing to use (or
> support) a closed OS can cope with also using the free-as-in-beer
> closed compiler provided by the vendor of that OS.

The problem with the MS "free" compilers is that it's only a
*temporary* freedom. They have a habit of withdrawing older
versions when newer ones become available. Together with their
other obnoxious habit of changing the C runtime in incompatible
ways with every release, the result is that extensions for
versions of Python older than N years can no longer be compiled
with any legally-available free MS compiler.

If you're talking about pragmatism, I think this situation
causes very pragmatic difficulties.

-- 
Greg

From greg.ewing at canterbury.ac.nz  Sun Aug  8 03:41:56 2010
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sun, 08 Aug 2010 13:41:56 +1200
Subject: [Python-Dev] Adding a token
Message-ID: <4C5E0B64.4060602@canterbury.ac.nz>

I'm trying to add a '?' token to the parser, and weird things
are happening.

I've added a #define to token.h, an entry to _PyParser_TokenNames
in tokenizer.c and case for it in PyToken_OneChar(). But it's
behaving as though the tokenizer is not recognising my token.

I put in some printfs to find out whether PyToken_OneChar() is
recognising it. The results are confusing: while running
pgen, PyToken_OneChar() is being called and recognising the
new token correctly.

However, it doesn't seem to be getting called *at all* when
parsing Python code. I don't see how this can happen, because
pgen seems to use the same tokenizing code as Python itself.

Is there anything else I need to do? Does some file need
to be manually re-made?

-- 
Greg

From benjamin at python.org  Sun Aug  8 03:42:33 2010
From: benjamin at python.org (Benjamin Peterson)
Date: Sat, 7 Aug 2010 20:42:33 -0500
Subject: [Python-Dev] Adding a token
In-Reply-To: <4C5E0B64.4060602@canterbury.ac.nz>
References: <4C5E0B64.4060602@canterbury.ac.nz>
Message-ID: <AANLkTim3Ay4tM=uvdjh0f0JYf8xP+wca7yV60_Hw=bVZ@mail.gmail.com>

2010/8/7 Greg Ewing <greg.ewing at canterbury.ac.nz>:
> I'm trying to add a '?' token to the parser, and weird things
> are happening.

Why do you even have to add a new token? You can just put the literal
'?' in the grammar.




-- 
Regards,
Benjamin

From greg.ewing at canterbury.ac.nz  Sun Aug  8 04:43:48 2010
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sun, 08 Aug 2010 14:43:48 +1200
Subject: [Python-Dev] Adding a token
In-Reply-To: <AANLkTim3Ay4tM=uvdjh0f0JYf8xP+wca7yV60_Hw=bVZ@mail.gmail.com>
References: <4C5E0B64.4060602@canterbury.ac.nz>
	<AANLkTim3Ay4tM=uvdjh0f0JYf8xP+wca7yV60_Hw=bVZ@mail.gmail.com>
Message-ID: <4C5E19E4.9060402@canterbury.ac.nz>

Benjamin Peterson wrote:

> Why do you even have to add a new token? You can just put the literal
> '?' in the grammar.

I don't see how that can be sufficient. All the other tokens
have entries in the three places I mentioned, and there's
no way that pgen can generate those automatically just from
seeing a '?' in the grammar.

I just tried an experiment -- I changed the grammar to accept
'?' as an alternative to '+', and tried to use the parser
module to parse "1?2". It reported a SyntaxError.

-- 
Greg

From steve at holdenweb.com  Sun Aug  8 05:40:54 2010
From: steve at holdenweb.com (Steve Holden)
Date: Sat, 07 Aug 2010 23:40:54 -0400
Subject: [Python-Dev] mingw support?
In-Reply-To: <4C5E07FB.8070203@canterbury.ac.nz>
References: <20100807195541.GA13990@laptop.gs>	<AANLkTim+WHSzUgS8HLnQbSaK=kYjUUNKArdxiSsnycFz@mail.gmail.com>
	<4C5E07FB.8070203@canterbury.ac.nz>
Message-ID: <i3l907$amb$1@dough.gmane.org>

On 8/7/2010 9:27 PM, Greg Ewing wrote:
> Nick Coghlan wrote:
> 
>> This used to be more of an issue because MS didn't provide a decent
>> free compiler for their platform. These days (since the release of
>> Visual Studio Express), we expect that people willing to use (or
>> support) a closed OS can cope with also using the free-as-in-beer
>> closed compiler provided by the vendor of that OS.
> 
> The problem with the MS "free" compilers is that it's only a
> *temporary* freedom. They have a habit of withdrawing older
> versions when newer ones become available. Together with their
> other obnoxious habit of changing the C runtime in incompatible
> ways with every release, the result is that extensions for
> versions of Python older than N years can no longer be compiled
> with any legally-available free MS compiler.
> 
> If you're talking about pragmatism, I think this situation
> causes very pragmatic difficulties.
> 
+0.5

Using the MS stuff is a pragmatic solution in the first place, since it
allows the software to be released. It's true that there may be problems
down the line. Microsoft's recent apparent reduction of support for
dynamic languages represents a disturbing trend to me, though that is
not directly related to the question raised by this thread.

regards
 Steve
-- 
Steve Holden           +1 571 484 6266   +1 800 494 3119
DjangoCon US September 7-9, 2010    http://djangocon.us/
See Python Video!       http://python.mirocommunity.org/
Holden Web LLC                 http://www.holdenweb.com/


From greg.ewing at canterbury.ac.nz  Sun Aug  8 06:15:57 2010
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sun, 08 Aug 2010 16:15:57 +1200
Subject: [Python-Dev] Adding a token
In-Reply-To: <4C5E19E4.9060402@canterbury.ac.nz>
References: <4C5E0B64.4060602@canterbury.ac.nz>
	<AANLkTim3Ay4tM=uvdjh0f0JYf8xP+wca7yV60_Hw=bVZ@mail.gmail.com>
	<4C5E19E4.9060402@canterbury.ac.nz>
Message-ID: <4C5E2F7D.5080203@canterbury.ac.nz>

Aaargh, I think I've found out what the problem is.

I'm using framework builds on MacOSX. I have two experimental
builds of Python 3.1 around, plus a standard one installed in
/Library. It's picking up the version of Python.framework in
/Library/Frameworks instead of the one in the local build
directory that python.exe was explicitly linked with.

Now I'm confused about why my *other* experimental build
worked -- the one I've been using for yield-from and codef --
because it should have suffered from the same problem. And
when I tried to use it again just now, it did indeed not work.

Does anyone know if there's a way to tell Apple's linker to
use a framework from a specific location and not go looking
anywhere else?

In the meantime, I think I'll switch to a non-framework
build for this project.

-- 
Greg

From krstic at solarsail.hcs.harvard.edu  Sun Aug  8 07:43:32 2010
From: krstic at solarsail.hcs.harvard.edu (=?utf-8?Q?Ivan_Krsti=C4=87?=)
Date: Sat, 7 Aug 2010 22:43:32 -0700
Subject: [Python-Dev] Adding a token
In-Reply-To: <4C5E2F7D.5080203@canterbury.ac.nz>
References: <4C5E0B64.4060602@canterbury.ac.nz>
	<AANLkTim3Ay4tM=uvdjh0f0JYf8xP+wca7yV60_Hw=bVZ@mail.gmail.com>
	<4C5E19E4.9060402@canterbury.ac.nz>
	<4C5E2F7D.5080203@canterbury.ac.nz>
Message-ID: <C61CFDD1-B84E-4824-B5C1-3EA5EAF08E87@solarsail.hcs.harvard.edu>

On Aug 7, 2010, at 9:15 PM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Does anyone know if there's a way to tell Apple's linker to
> use a framework from a specific location and not go looking
> anywhere else?

$ DYLD_FRAMEWORK_PATH=<path> <command>

See dyld(1) for other relevant magic. 

Cheers,

--
Ivan Krsti?, via mobile
> 

From nad at acm.org  Sun Aug  8 08:27:25 2010
From: nad at acm.org (Ned Deily)
Date: Sat, 07 Aug 2010 23:27:25 -0700
Subject: [Python-Dev] Adding a token
References: <4C5E0B64.4060602@canterbury.ac.nz>
	<AANLkTim3Ay4tM=uvdjh0f0JYf8xP+wca7yV60_Hw=bVZ@mail.gmail.com>
	<4C5E19E4.9060402@canterbury.ac.nz>
	<4C5E2F7D.5080203@canterbury.ac.nz>
Message-ID: <nad-1267AD.23272507082010@news.gmane.org>

In article <4C5E2F7D.5080203 at canterbury.ac.nz>,
 Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Does anyone know if there's a way to tell Apple's linker to
> use a framework from a specific location and not go looking
> anywhere else?

I haven't tested it myself but you should be able to prevent problems 
like that by specifying a non-default framework name with the 
--with-framework-name= option to configure.  See Mac/README.

-- 
 Ned Deily,
 nad at acm.org


From regebro at gmail.com  Sun Aug  8 10:37:21 2010
From: regebro at gmail.com (Lennart Regebro)
Date: Sun, 8 Aug 2010 10:37:21 +0200
Subject: [Python-Dev] Add aware local time support to datetime module
In-Reply-To: <AANLkTinXNr8F6mGb2X8Bbj42Ou1OuUwiAmW+dE9nByYv@mail.gmail.com>
References: <AANLkTinwyUr0cwQJFz-A=ojQcDadCcwLgqLkqhgTA46a@mail.gmail.com> 
	<AANLkTinXNr8F6mGb2X8Bbj42Ou1OuUwiAmW+dE9nByYv@mail.gmail.com>
Message-ID: <AANLkTin2nCrECs7HsMZPmq9huEf+daLWANX3pAe4U8MX@mail.gmail.com>

On Wed, Aug 4, 2010 at 19:46, Alexander Belopolsky
<alexander.belopolsky at gmail.com> wrote:
> [I've got no response from python-ideas, so I am forwarding to python-dev.]
>
> With addition of fixed offset timezone class and the timezone.utc
> instance [0], it is easy to get UTC time as an aware datetime
> instance:
>
>>>> datetime.now(timezone.utc)
> datetime.datetime(2010, 8, 3, 14, 16, 10, 670308, tzinfo=datetime.timezone.utc)
>
> However, if you want to keep time in your local timezone, getting an
> aware datetime is almost a catch 22. ?If you know your timezone UTC
> offset, you can do
>
>>>> EDT = timezone(timedelta(hours=-4))
>>>> datetime.now(EDT)
> datetime.datetime(2010, 8, 3, 10, 20, 23, 769537,
> tzinfo=datetime.timezone(datetime.timedelta(-1, 72000)))
>
> but the problem is that there is no obvious or even correct way to
> find local timezone UTC offset. [1]
>
> In a comment on issue #5094 ("datetime lacks concrete tzinfo
> implementation for UTC"), I proposed to address this problem in a
> localtime([t]) function that would return current time (or time
> corresponding to the optional datetime argument) as an aware datetime
> object carrying local timezone information in a tzinfo set to an
> appropriate timezone instance. ? This solution is attractive by its
> simplicity, but there are several problems:
>
> 1. An aware datetime cannot carry all information that system
> localtime() supplies in a time tuple. ?Specifically, the is_dst flag
> is lost. ?This is not a problem for most applications as long as
> timezone UTC offset and timezone name are available, but may be an
> issue when interoperability with the time module is required.
>
> 2. ?Datetime's tzinfo interface was designed with the idea that
> <2010-11-06 12:00 EDT> + <1 day> = ?<2010-11-07 12:00 EST>, not
> <2010-11-07 12:00 EDT>. It other words, if I have lunch with someone
> at noon (12:00 EDT) on Saturday the day before first Sunday in
> November, and want to meet again "at the same time tomorrow", I mean
> 12:00 EST, not 24 hours later. ?With localtime() returning datetime
> with tzinfo set to fixed offset timezone, however, localtime() ?+
> timedelta(1) will mean exactly 24 hours later and the result will be
> expressed in an unusual for the given location timezone.
>
> An alternative approach is the one recommended in the python manual.
> [3] ?One could implement a LocalTimezone class with utcoffset(),
> tzname() and dst() extracting information from system mktime and
> localtime calls. ?This approach has its own shortcomings:
>
> 1. While adding integral number of days to datetimes in business
> setting, it is natural to expect automatic timezone adjustments, it is
> not as clearcut when adding hours or minutes.
>
> 2. The tzinfo.utcoffset() interface that expects *standard* local time
> as an argument is confusing to many users. ?Even the "official"
> example in the python manual gets it wrong. [4]
>
> 3. datetime(..., tzinfo=LocalTimezone()) is ambiguous during the
> "repeated hour" when local clock is set back in DST to standard time
> transition.
>
> As far as I can tell, the only way to resolve the last problem is to
> add is_dst flag to the datetime object, which would also be the
> only way to achieve full interoperability between datetime objects and
> time tuples. [5]
>
> The traditional answer to call for improvement of timezone support in
> datetime module has been: "this is upto 3rd parties to implement."
> Unfortunately, stdlib is asking 3rd parties to implement an impossible
> interface without giving access to the necessary data. ? The
> impossibility comes from the requirement that dst() method should find
> out whether local time represents DST or standard time while there is
> an hour each year when the same local time can be either. ?The missing
> data is the system UTC offset when it changes historically. ?The time
> module only gives access to the current UTC offset.
>
> My preference is to implement the first alternative - localtime([t])
> returning aware datetime with fixed offset timezone. ?This will solve
> the problem of python's lack of access to the universally available
> system facilities that are necessary to implement any kind of aware
> local time support.

For all of the reasons you give above, I think it's a bad idea. :-)

You need a proper time zone database to solve these issues, like pytz.
Which incidentally solves the ambiguity problem as well. so the
solution is pytz. :-)
What pytz doesn't have (but dateutil.tz does) is a timezone object
that uses the operating systems local timezone data, like
/etc/localzone on unix. That could be interesting to include,
possibly. Having a fixed time zone offset object for the localtime
seems a bad idea. The problem it solves is easy to get around, but the
problems created are not.

-- 
Lennart Regebro, Colliberty: http://www.colliberty.com/
Python, Zope, Plone blog: http://regebro.wordpress.com/
Telephone: +33 661 58 14 64

From martin at v.loewis.de  Sun Aug  8 11:05:22 2010
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 08 Aug 2010 11:05:22 +0200
Subject: [Python-Dev] mingw support?
In-Reply-To: <4C5E07FB.8070203@canterbury.ac.nz>
References: <20100807195541.GA13990@laptop.gs>	<AANLkTim+WHSzUgS8HLnQbSaK=kYjUUNKArdxiSsnycFz@mail.gmail.com>
	<4C5E07FB.8070203@canterbury.ac.nz>
Message-ID: <4C5E7352.1050901@v.loewis.de>

Am 08.08.2010 03:27, schrieb Greg Ewing:
> Nick Coghlan wrote:
> 
>> This used to be more of an issue because MS didn't provide a decent
>> free compiler for their platform. These days (since the release of
>> Visual Studio Express), we expect that people willing to use (or
>> support) a closed OS can cope with also using the free-as-in-beer
>> closed compiler provided by the vendor of that OS.
> 
> The problem with the MS "free" compilers is that it's only a
> *temporary* freedom. They have a habit of withdrawing older
> versions when newer ones become available. Together with their
> other obnoxious habit of changing the C runtime in incompatible
> ways with every release, the result is that extensions for
> versions of Python older than N years can no longer be compiled
> with any legally-available free MS compiler.

However, this is out of scope for the question at hand. Compiling
extensions with mingw is fairly well supported, and people contribute
small patches when it breaks.

The OP was asking for compilation of Python itself with mingw, for
which this MS policy hasn't caused problems - I do have all the
compilers available to me that I need to do that.

Indeed, MSDN subscribers can still access older compiler versions
for quite some time after Microsoft stopped otherwise distributing
the product.

Regards,
Martin

From asmodai at in-nomine.org  Sun Aug  8 17:55:15 2010
From: asmodai at in-nomine.org (Jeroen Ruigrok van der Werven)
Date: Sun, 8 Aug 2010 17:55:15 +0200
Subject: [Python-Dev] mingw support?
In-Reply-To: <AANLkTim+WHSzUgS8HLnQbSaK=kYjUUNKArdxiSsnycFz@mail.gmail.com>
References: <20100807195541.GA13990@laptop.gs>
	<AANLkTim+WHSzUgS8HLnQbSaK=kYjUUNKArdxiSsnycFz@mail.gmail.com>
Message-ID: <20100808155515.GA51334@nexus.in-nomine.org>

-On [20100808 02:23], Nick Coghlan (ncoghlan at gmail.com) wrote:
>This used to be more of an issue because MS didn't provide a decent
>free compiler for their platform. These days (since the release of
>Visual Studio Express), we expect that people willing to use (or
>support) a closed OS can cope with also using the free-as-in-beer
>closed compiler provided by the vendor of that OS.

You don't even need VS Express.

Install Windows SDK 7.1 and the compilers are supplied with it. Less clutter
if you prefer the command line.

-- 
Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
????? ?????? ??? ?? ??????
http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B
Without a soul there can be no understanding between the heart and the mind.

From ncoghlan at gmail.com  Sun Aug  8 18:29:03 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 9 Aug 2010 02:29:03 +1000
Subject: [Python-Dev] mingw support?
In-Reply-To: <20100808155515.GA51334@nexus.in-nomine.org>
References: <20100807195541.GA13990@laptop.gs>
	<AANLkTim+WHSzUgS8HLnQbSaK=kYjUUNKArdxiSsnycFz@mail.gmail.com>
	<20100808155515.GA51334@nexus.in-nomine.org>
Message-ID: <AANLkTinMkf3mCp7oXrEv0do_LajdCxCiDAQ4AJdJ96Gc@mail.gmail.com>

On Mon, Aug 9, 2010 at 1:55 AM, Jeroen Ruigrok van der Werven
<asmodai at in-nomine.org> wrote:
> -On [20100808 02:23], Nick Coghlan (ncoghlan at gmail.com) wrote:
>>This used to be more of an issue because MS didn't provide a decent
>>free compiler for their platform. These days (since the release of
>>Visual Studio Express), we expect that people willing to use (or
>>support) a closed OS can cope with also using the free-as-in-beer
>>closed compiler provided by the vendor of that OS.
>
> You don't even need VS Express.
>
> Install Windows SDK 7.1 and the compilers are supplied with it. Less clutter
> if you prefer the command line.

MS may have improved the tools they release with the SDK to the point
where they can build a VS solution file (I haven't tried that in
years). Historically (i.e. before the first express version of Visual
Studio), there were a lot of hoops to jump through to get something
that could handle the complete build chain. It was painful enough back
when I first started hacking on the Python core that I gave up and
just switched to developing on Linux instead.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From asmodai at in-nomine.org  Sun Aug  8 18:45:50 2010
From: asmodai at in-nomine.org (Jeroen Ruigrok van der Werven)
Date: Sun, 8 Aug 2010 18:45:50 +0200
Subject: [Python-Dev] mingw support?
In-Reply-To: <AANLkTinMkf3mCp7oXrEv0do_LajdCxCiDAQ4AJdJ96Gc@mail.gmail.com>
References: <20100807195541.GA13990@laptop.gs>
	<AANLkTim+WHSzUgS8HLnQbSaK=kYjUUNKArdxiSsnycFz@mail.gmail.com>
	<20100808155515.GA51334@nexus.in-nomine.org>
	<AANLkTinMkf3mCp7oXrEv0do_LajdCxCiDAQ4AJdJ96Gc@mail.gmail.com>
Message-ID: <20100808164550.GB51334@nexus.in-nomine.org>

-On [20100808 18:29], Nick Coghlan (ncoghlan at gmail.com) wrote:
>MS may have improved the tools they release with the SDK to the point
>where they can build a VS solution file (I haven't tried that in
>years).

>From my quick glance of what the current SDK installs that does to seem to
be the case. I have not tried it myself (yet).

-- 
Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
????? ?????? ??? ?? ??????
http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B
You yourself, as much as anybody in the entire universe, deserve your love
and affection...

From tjreedy at udel.edu  Sun Aug  8 21:54:44 2010
From: tjreedy at udel.edu (Terry Reedy)
Date: Sun, 08 Aug 2010 15:54:44 -0400
Subject: [Python-Dev] mingw support?
In-Reply-To: <20100807195541.GA13990@laptop.gs>
References: <20100807195541.GA13990@laptop.gs>
Message-ID: <i3n225$osp$1@dough.gmane.org>

On 8/7/2010 3:55 PM, linux at gabriel-striewe.de wrote:
> Dear list,
>
> I was wondering whether there would ever be support for python to be
> build by the mingw compiler suite. I found a few patches in the
> internet but there were disagreeing comments on whether they are
> functional or not.
>
> So I would like to ask the list whether there are any technical
> reasons that this is so.

The sociological problem is that currently not enough advocates of using 
a free-as-in-thought compiler both can and will provide enough 
free-as-in-beer volunteer time to deal with the sociological and 
technical problems. That could change someday.

I suspect that the persons who first ported Python to MSDOS simply used 
what they were used to using, perhaps in their paid job. And I am sure 
that is still true of at least some of the people doing Windows support 
today.

-- 
Terry Jan Reedy


From tjreedy at udel.edu  Sun Aug  8 22:03:07 2010
From: tjreedy at udel.edu (Terry Reedy)
Date: Sun, 08 Aug 2010 16:03:07 -0400
Subject: [Python-Dev] Was Tracker Summary sent Fri Aug 6?\
Message-ID: <i3n2hr$qfq$1@dough.gmane.org>

The usual Friday Summary of Python Trackers Issues did not appear on 
Gmane. Was one generated? Or did it just fail to make it to gmane?
I use to to review new issues, so even late would be better than never.

-- 
Terry Jan Reedy


From martin at v.loewis.de  Sun Aug  8 22:17:17 2010
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 08 Aug 2010 22:17:17 +0200
Subject: [Python-Dev] Was Tracker Summary sent Fri Aug 6?\
In-Reply-To: <i3n2hr$qfq$1@dough.gmane.org>
References: <i3n2hr$qfq$1@dough.gmane.org>
Message-ID: <4C5F10CD.60005@v.loewis.de>

Am 08.08.2010 22:03, schrieb Terry Reedy:
> The usual Friday Summary of Python Trackers Issues did not appear on
> Gmane. Was one generated? 

Sending it failed due to a hard disk problem.

Regards,
Martin

From solipsis at pitrou.net  Sun Aug  8 23:49:37 2010
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sun, 8 Aug 2010 23:49:37 +0200
Subject: [Python-Dev] Return code when there's a problem at shutdown
Message-ID: <20100808234937.3095ba2b@pitrou.net>


Hello,

In issue #5319, the poster complains that redirecting stdout to a
misbehaving (pseudo-)file such as /dev/full should produce a non-zero
error code when the IO error happens at shutdown (when calling flush()
on stdout).

Is it a reasonable expectation? What would you think of making the
change?
(it would require giving a return value to Py_Finalize(), which
currently returns nothing)

Regards

Antoine.



From benjamin at python.org  Mon Aug  9 00:14:55 2010
From: benjamin at python.org (Benjamin Peterson)
Date: Sun, 8 Aug 2010 17:14:55 -0500
Subject: [Python-Dev] [Python-checkins] r83860 -
	python/branches/py3k/Python/_warnings.c
In-Reply-To: <20100808221245.76A02EEA0C@mail.python.org>
References: <20100808221245.76A02EEA0C@mail.python.org>
Message-ID: <AANLkTinG=XTbp7YWfgZVuYOXCaCQ1SniEE1RZw5dZ1Lf@mail.gmail.com>

2010/8/8 victor.stinner <python-checkins at python.org>:
> Author: victor.stinner
> Date: Mon Aug ?9 00:12:45 2010
> New Revision: 83860
>
> Log:
> Issue #9425: fix setup_context() for non-ascii filenames

Test?



-- 
Regards,
Benjamin

From nyamatongwe at gmail.com  Mon Aug  9 00:41:58 2010
From: nyamatongwe at gmail.com (Neil Hodgson)
Date: Mon, 9 Aug 2010 08:41:58 +1000
Subject: [Python-Dev] mingw support?
In-Reply-To: <i3n225$osp$1@dough.gmane.org>
References: <20100807195541.GA13990@laptop.gs> <i3n225$osp$1@dough.gmane.org>
Message-ID: <AANLkTi=dc=0brYo34=xaU6D9wH97eB_tTN=b=FBNjLNh@mail.gmail.com>

Terry Reedy:

> I suspect that the persons who first ported Python to MSDOS simply used what
> they were used to using, perhaps in their paid job. And I am sure that is
> still true of at least some of the people doing Windows support today.

   Some Windows developers actually prefer Visual Studio, including me.

   MingW has become less attractive in recent years by the difficulty
in downloading and installing a current version and finding out how to
do so. Some projects have moved on to the TDM packaging of MingW.

http://tdm-gcc.tdragon.net/

   Neil

From tjreedy at udel.edu  Mon Aug  9 00:49:50 2010
From: tjreedy at udel.edu (Terry Reedy)
Date: Sun, 08 Aug 2010 18:49:50 -0400
Subject: [Python-Dev] Return code when there's a problem at shutdown
In-Reply-To: <20100808234937.3095ba2b@pitrou.net>
References: <20100808234937.3095ba2b@pitrou.net>
Message-ID: <i3ncag$l93$1@dough.gmane.org>

On 8/8/2010 5:49 PM, Antoine Pitrou wrote:
>
> Hello,
>
> In issue #5319, the poster complains that redirecting stdout to a
> misbehaving (pseudo-)file such as /dev/full should produce a non-zero
> error code when the IO error happens at shutdown (when calling flush()
> on stdout).

I think is worth noting that in the artificial example,
python2.5 -c 'print((1, 2, 3))' > /dev/full || echo error status
the redirection occurs outside (before) the program operation.
>
> Is it a reasonable expectation? What would you think of making the
> change?

It depends on whether or not one considers shutdown operations as part 
of the program operation. I could argue this either way.

In the above example, I could say that Python did what it promised to do 
-- print something to the stdout stream, and that failure on flushing 
was outside its purview.

I could also say that if one wants the flush to be considered part of 
the program operation, one should put it in the program explicitly 
instead of depending on implicit operations after the program ended.

> (it would require giving a return value to Py_Finalize(), which
> currently returns nothing)

I have the impression that finalization sometimes generates bogus errors 
due the order of operations. If so returning something would require 
distinguishing between 'proper' and 'bogus' errors. How easy would that 
be. If non-trivial, I would go back to "If you want shutdown errors 
reported, put them in the program explicitly."

-- 
Terry Jan Reedy


From solipsis at pitrou.net  Mon Aug  9 01:48:24 2010
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 9 Aug 2010 01:48:24 +0200
Subject: [Python-Dev] r83869 - in python/branches/py3k:
 Doc/library/socket.rst Doc/whatsnew/3.2.rst Lib/ssl.py
 Lib/test/test_socket.py Misc/NEWS Modules/socketmodule.c
References: <20100808232450.7660BEEA37@mail.python.org>
Message-ID: <20100809014824.3b4b713f@pitrou.net>

On Mon,  9 Aug 2010 01:24:50 +0200 (CEST)
antoine.pitrou <python-checkins at python.org> wrote:
> Author: antoine.pitrou
> Date: Mon Aug  9 01:24:50 2010
> New Revision: 83869
> 
> Log:
> Issue #8524: Add a forget() method to socket objects, so as to put the
> socket into the closed state without closing the underlying file
> descriptor.

Benjamin suggested to call this detach() instead. What do you think?

Thanks

Antoine.



From eric at trueblade.com  Mon Aug  9 01:53:38 2010
From: eric at trueblade.com (Eric Smith)
Date: Sun, 08 Aug 2010 19:53:38 -0400
Subject: [Python-Dev] r83869 - in python/branches/py3k:
 Doc/library/socket.rst Doc/whatsnew/3.2.rst Lib/ssl.py
 Lib/test/test_socket.py Misc/NEWS Modules/socketmodule.c
In-Reply-To: <20100809014824.3b4b713f@pitrou.net>
References: <20100808232450.7660BEEA37@mail.python.org>
	<20100809014824.3b4b713f@pitrou.net>
Message-ID: <4C5F4382.8040103@trueblade.com>

On 8/8/10 7:48 PM, Antoine Pitrou wrote:
> On Mon,  9 Aug 2010 01:24:50 +0200 (CEST)
> antoine.pitrou<python-checkins at python.org>  wrote:
>> Author: antoine.pitrou
>> Date: Mon Aug  9 01:24:50 2010
>> New Revision: 83869
>>
>> Log:
>> Issue #8524: Add a forget() method to socket objects, so as to put the
>> socket into the closed state without closing the underlying file
>> descriptor.
>
> Benjamin suggested to call this detach() instead. What do you think?

detach() is the name I've seen most often for this. For example, that's 
what MFC uses:
http://msdn.microsoft.com/en-us/library/7zhdchw8(VS.80).aspx

-- 
Eric.

From solipsis at pitrou.net  Mon Aug  9 01:56:55 2010
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 9 Aug 2010 01:56:55 +0200
Subject: [Python-Dev] Return code when there's a problem at shutdown
References: <20100808234937.3095ba2b@pitrou.net> <i3ncag$l93$1@dough.gmane.org>
Message-ID: <20100809015655.27f1bdab@pitrou.net>

On Sun, 08 Aug 2010 18:49:50 -0400
Terry Reedy <tjreedy at udel.edu> wrote:
> 
> In the above example, I could say that Python did what it promised to do 
> -- print something to the stdout stream, and that failure on flushing 
> was outside its purview.
> 
> I could also say that if one wants the flush to be considered part of 
> the program operation, one should put it in the program explicitly 
> instead of depending on implicit operations after the program ended.

Good point. It isn't very hard to call stdout.flush() yourself if you
are using stdout as a data stream, and want the user to be notified of
errors.

Similarly, if deallocating a file object produces an error during the
interpreter's lifetime, the error is printed out on stderr and then
ignored.

Regards

Antoine.



From mail at timgolden.me.uk  Mon Aug  9 07:01:45 2010
From: mail at timgolden.me.uk (Tim Golden)
Date: Mon, 09 Aug 2010 06:01:45 +0100
Subject: [Python-Dev] [Python-checkins] r83831 - in
 python/branches/release31-maint/Lib: subprocess.py test/test_subprocess.py
In-Reply-To: <4C5F3038.40401@trueblade.com>
References: <20100808161818.48FB9EE99A@mail.python.org>
	<4C5F3038.40401@trueblade.com>
Message-ID: <4C5F8BB9.7000309@timgolden.me.uk>

On 08/08/2010 11:31 PM, Eric Smith wrote:
> On 8/8/10 12:18 PM, tim.golden wrote:
>> Modified: python/branches/release31-maint/Lib/subprocess.py
>> ==============================================================================
>> --- python/branches/release31-maint/Lib/subprocess.py	(original)
>> +++ python/branches/release31-maint/Lib/subprocess.py	Sun Aug  8 18:18:18 2010
>> @@ -829,7 +829,7 @@
>>                    startupinfo.dwFlags |= _subprocess.STARTF_USESHOWWINDOW
>>                    startupinfo.wShowWindow = _subprocess.SW_HIDE
>>                    comspec = os.environ.get("COMSPEC", "cmd.exe")
>> -                args = comspec + " /c " + args
>> +                args = comspec + " /c " + '"%s"' % args
>>                    if (_subprocess.GetVersion()>= 0x80000000 or
>>                            os.path.basename(comspec).lower() == "command.com"):
>>                        # Win9x, or using command.com on NT. We need to
>
> If args is a tuple, this fails with a TypeError. I realize args
> shouldn't be a tuple, but that's not a great failure if it is. I think
> this would be better written as:
>
>        args = '{} /c "{}"'.format(compspec, args)
>
>

Thanks, Eric. I'll rework.

TJG

From greg.ewing at canterbury.ac.nz  Mon Aug  9 10:34:26 2010
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Mon, 09 Aug 2010 20:34:26 +1200
Subject: [Python-Dev] Bug in 3.1.2 site.py
Message-ID: <4C5FBD92.5080202@canterbury.ac.nz>

I think I've found a bug in the site.py of 3.1.2.
The following piece of code tries to make the modules
that are normally installed under lib-dynload available
when running from the build directory:

     """Append ./build/lib.<platform> in case we're running in the build dir
     (especially for Guido :-)"""
     from distutils.util import get_platform
     s = "build/lib.%s-%.3s" % (get_platform(), sys.version)
     if hasattr(sys, 'gettotalrefcount'):
         s += '-pydebug'
     s = os.path.join(os.path.dirname(sys.path[-1]), s)
     sys.path.append(s)

However, it doesn't always work, because distutils.util.get_platform
tries to find a Makefile in the install location, which
doesn't exist if the Python you're building has never been
installed!

-- 
Greg

From ncoghlan at gmail.com  Mon Aug  9 14:16:24 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 9 Aug 2010 22:16:24 +1000
Subject: [Python-Dev] [Python-checkins] r83885 - in
	python/branches/py3k: Lib/re.py Lib/test/test_re.py Misc/NEWS
In-Reply-To: <20100809104746.3E742EE9DF@mail.python.org>
References: <20100809104746.3E742EE9DF@mail.python.org>
Message-ID: <AANLkTin6XT-0XyKS940b9ofGbXWNUJiFxnZDDHEaYJkB@mail.gmail.com>

On Mon, Aug 9, 2010 at 8:47 PM, antoine.pitrou
<python-checkins at python.org> wrote:
> Author: antoine.pitrou
> Date: Mon Aug ?9 12:47:46 2010
> New Revision: 83885
>
> Log:
> Revert r83877 in order to fix compilation

Is this still a problem even after the later checkins to fix the
circular build dependency by adding _collections to the static part of
the build?

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From orsenthil at gmail.com  Mon Aug  9 14:25:10 2010
From: orsenthil at gmail.com (Senthil Kumaran)
Date: Mon, 9 Aug 2010 17:55:10 +0530
Subject: [Python-Dev] [Python-checkins] r83885 - in
 python/branches/py3k: Lib/re.py Lib/test/test_re.py Misc/NEWS
In-Reply-To: <AANLkTin6XT-0XyKS940b9ofGbXWNUJiFxnZDDHEaYJkB@mail.gmail.com>
References: <20100809104746.3E742EE9DF@mail.python.org>
	<AANLkTin6XT-0XyKS940b9ofGbXWNUJiFxnZDDHEaYJkB@mail.gmail.com>
Message-ID: <20100809122510.GA3292@remy>

On Mon, Aug 09, 2010 at 10:16:24PM +1000, Nick Coghlan wrote:
> On Mon, Aug 9, 2010 at 8:47 PM, antoine.pitrou
> > Log:
> > Revert r83877 in order to fix compilation
> 
> Is this still a problem even after the later checkins to fix the
> circular build dependency by adding _collections to the static part of
> the build?
 
The buildbot page said this:

Modules/Setup.dist is newer than Modules/Setup;
check to make sure you have all the updates you
need in your Modules/Setup file.
Usually, copying Modules/Setup.dist to Modules/Setup will work.


Do you know what needs to done for making Modules/Setup to reflect
the changes in Modules/Setup.dist in the buildbots?
On local checkouts, the compilation goes fine.


-- 
Senthil

We all agree on the necessity of compromise.  We just can't agree on
when it's necessary to compromise.
		-- Larry Wall

From solipsis at pitrou.net  Mon Aug  9 14:31:52 2010
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 9 Aug 2010 14:31:52 +0200
Subject: [Python-Dev] r83885 - in python/branches/py3k: Lib/re.py
 Lib/test/test_re.py Misc/NEWS
References: <20100809104746.3E742EE9DF@mail.python.org>
	<AANLkTin6XT-0XyKS940b9ofGbXWNUJiFxnZDDHEaYJkB@mail.gmail.com>
Message-ID: <20100809143152.19140e29@pitrou.net>

On Mon, 9 Aug 2010 22:16:24 +1000
Nick Coghlan <ncoghlan at gmail.com> wrote:

> On Mon, Aug 9, 2010 at 8:47 PM, antoine.pitrou
> <python-checkins at python.org> wrote:
> > Author: antoine.pitrou
> > Date: Mon Aug ?9 12:47:46 2010
> > New Revision: 83885
> >
> > Log:
> > Revert r83877 in order to fix compilation
> 
> Is this still a problem even after the later checkins to fix the
> circular build dependency by adding _collections to the static part of
> the build?

Yes, it is.
Apparently, there is another problem remaining:

Traceback (most recent call last):
  File "./setup.py", line 7, in <module>
    from glob import glob
  File "/scratch/pybot-buildarea/3.x.klose-ubuntu-i386/build/Lib/glob.py", line 6, in <module>
    import fnmatch
  File "/scratch/pybot-buildarea/3.x.klose-ubuntu-i386/build/Lib/fnmatch.py", line 15, in <module>
    import functools
  File "/scratch/pybot-buildarea/3.x.klose-ubuntu-i386/build/Lib/functools.py", line 15, in <module>
    from collections import OrderedDict, Counter
  File "/scratch/pybot-buildarea/3.x.klose-ubuntu-i386/build/Lib/collections.py", line 9, in <module>
    from _collections import deque, defaultdict
ImportError: No module named _collections
[31908 refs]
make: *** [sharedmods] Error 1

http://www.python.org/dev/buildbot/builders/i386%20Ubuntu%203.x/builds/1838/steps/compile/logs/stdio





From ncoghlan at gmail.com  Mon Aug  9 14:34:18 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 9 Aug 2010 22:34:18 +1000
Subject: [Python-Dev] [Python-checkins] r83885 - in
	python/branches/py3k: Lib/re.py Lib/test/test_re.py Misc/NEWS
In-Reply-To: <20100809122510.GA3292@remy>
References: <20100809104746.3E742EE9DF@mail.python.org>
	<AANLkTin6XT-0XyKS940b9ofGbXWNUJiFxnZDDHEaYJkB@mail.gmail.com>
	<20100809122510.GA3292@remy>
Message-ID: <AANLkTimHQR0ME5BRLGc2jsfQ3MvMXfTUgvKtpnwj-uJ_@mail.gmail.com>

On Mon, Aug 9, 2010 at 10:25 PM, Senthil Kumaran <orsenthil at gmail.com> wrote:
> Do you know what needs to done for making Modules/Setup to reflect
> the changes in Modules/Setup.dist in the buildbots?
> On local checkouts, the compilation goes fine.

The buildbot checkout scripts should probably do that copy as a matter
of course. There's no reason to support local modifications of
Modules/Setup on the buildbots.

Cheers,
Nick.


-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From solipsis at pitrou.net  Mon Aug  9 14:46:09 2010
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 9 Aug 2010 14:46:09 +0200
Subject: [Python-Dev] r83885 - in python/branches/py3k: Lib/re.py
 Lib/test/test_re.py Misc/NEWS
References: <20100809104746.3E742EE9DF@mail.python.org>
	<AANLkTin6XT-0XyKS940b9ofGbXWNUJiFxnZDDHEaYJkB@mail.gmail.com>
	<20100809122510.GA3292@remy>
	<AANLkTimHQR0ME5BRLGc2jsfQ3MvMXfTUgvKtpnwj-uJ_@mail.gmail.com>
Message-ID: <20100809144609.4165ca24@pitrou.net>

On Mon, 9 Aug 2010 22:34:18 +1000
Nick Coghlan <ncoghlan at gmail.com> wrote:
> On Mon, Aug 9, 2010 at 10:25 PM, Senthil Kumaran <orsenthil at gmail.com> wrote:
> > Do you know what needs to done for making Modules/Setup to reflect
> > the changes in Modules/Setup.dist in the buildbots?
> > On local checkouts, the compilation goes fine.
> 
> The buildbot checkout scripts should probably do that copy as a matter
> of course. There's no reason to support local modifications of
> Modules/Setup on the buildbots.

Florent found out that removing Modules/Setup is done as part of the
"clean" stage:
http://www.python.org/dev/buildbot/builders/i386%20Ubuntu%203.x/builds/1820/steps/clean/logs/stdio
but the "clean" stage doesn't get run after a compile error:
http://www.python.org/dev/buildbot/waterfall?show=x86%20gentoo%203.x

Regards

Antoine.



From ncoghlan at gmail.com  Mon Aug  9 14:56:19 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 9 Aug 2010 22:56:19 +1000
Subject: [Python-Dev] r83885 - in python/branches/py3k: Lib/re.py
	Lib/test/test_re.py Misc/NEWS
In-Reply-To: <20100809144609.4165ca24@pitrou.net>
References: <20100809104746.3E742EE9DF@mail.python.org>
	<AANLkTin6XT-0XyKS940b9ofGbXWNUJiFxnZDDHEaYJkB@mail.gmail.com>
	<20100809122510.GA3292@remy>
	<AANLkTimHQR0ME5BRLGc2jsfQ3MvMXfTUgvKtpnwj-uJ_@mail.gmail.com>
	<20100809144609.4165ca24@pitrou.net>
Message-ID: <AANLkTi=V8eKXiRmiK+JSYiFoRxyK00QZ7yqO7wC1bPVS@mail.gmail.com>

On Mon, Aug 9, 2010 at 10:46 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Mon, 9 Aug 2010 22:34:18 +1000
> Nick Coghlan <ncoghlan at gmail.com> wrote:
>> On Mon, Aug 9, 2010 at 10:25 PM, Senthil Kumaran <orsenthil at gmail.com> wrote:
>> > Do you know what needs to done for making Modules/Setup to reflect
>> > the changes in Modules/Setup.dist in the buildbots?
>> > On local checkouts, the compilation goes fine.
>>
>> The buildbot checkout scripts should probably do that copy as a matter
>> of course. There's no reason to support local modifications of
>> Modules/Setup on the buildbots.
>
> Florent found out that removing Modules/Setup is done as part of the
> "clean" stage:
> http://www.python.org/dev/buildbot/builders/i386%20Ubuntu%203.x/builds/1820/steps/clean/logs/stdio
> but the "clean" stage doesn't get run after a compile error:
> http://www.python.org/dev/buildbot/waterfall?show=x86%20gentoo%203.x

In that case, once you get a clean run through on the buildbots (with
the setup.py changes now in place), you should be OK to check the
fnmatch and re changes back in.

Longer term, the buildbot setup should be modified to run the cleanup
step even if the compilation step fails. I'm assume that is something
Martin needs to set up.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From fdrake at acm.org  Mon Aug  9 15:01:04 2010
From: fdrake at acm.org (Fred Drake)
Date: Mon, 9 Aug 2010 09:01:04 -0400
Subject: [Python-Dev] r83885 - in python/branches/py3k: Lib/re.py
	Lib/test/test_re.py Misc/NEWS
In-Reply-To: <AANLkTi=V8eKXiRmiK+JSYiFoRxyK00QZ7yqO7wC1bPVS@mail.gmail.com>
References: <20100809104746.3E742EE9DF@mail.python.org>
	<AANLkTin6XT-0XyKS940b9ofGbXWNUJiFxnZDDHEaYJkB@mail.gmail.com> 
	<20100809122510.GA3292@remy>
	<AANLkTimHQR0ME5BRLGc2jsfQ3MvMXfTUgvKtpnwj-uJ_@mail.gmail.com> 
	<20100809144609.4165ca24@pitrou.net>
	<AANLkTi=V8eKXiRmiK+JSYiFoRxyK00QZ7yqO7wC1bPVS@mail.gmail.com>
Message-ID: <AANLkTi=yYyNeXeb8XyHg7gWDhiwPuwu+AWgTJdYgsnNv@mail.gmail.com>

On Mon, Aug 9, 2010 at 8:56 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> Longer term, the buildbot setup should be modified to run the cleanup
> step even if the compilation step fails.

Running "make clean" after checkout/update should work as well.


? -Fred

--
Fred L. Drake, Jr.? ? <fdrake at gmail.com>
"A storm broke loose in my mind."? --Albert Einstein

From ncoghlan at gmail.com  Mon Aug  9 16:29:44 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 10 Aug 2010 00:29:44 +1000
Subject: [Python-Dev] [Python-checkins] r83890 -
	python/branches/py3k/Lib/inspect.py
In-Reply-To: <20100809130535.9F587EE9CA@mail.python.org>
References: <20100809130535.9F587EE9CA@mail.python.org>
Message-ID: <AANLkTikSeZsW3usOMmMPZ-SASokv1nDgoiydSy_5AQ66@mail.gmail.com>

On Mon, Aug 9, 2010 at 11:05 PM, benjamin.peterson
<python-checkins at python.org> wrote:
> -if hasattr(sys, '_getframe'):
> - ? ?currentframe = sys._getframe
> -else:
> - ? ?currentframe = lambda _=None: None
> +def currentframe():
> + ? ?"""Return the frame or the caller or None if this is not possible."""
> + ? ?return sys._getframe(1) if hasattr(sys, "_getframe") else None

It isn't hugely important, but with sys._getframe() unlikely to appear
during runtime, the following may make more sense:

if hasattr(sys, '_getframe'):
    def currentframe():
        return sys._getframe(1)
else:
    def currentframe():
        pass
currentframe.__doc__ = "Return the frame of the caller or None if this
is not possible."

(Oh, and there's a typo in the docstring...)

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From benjamin at python.org  Mon Aug  9 17:48:35 2010
From: benjamin at python.org (Benjamin Peterson)
Date: Mon, 9 Aug 2010 10:48:35 -0500
Subject: [Python-Dev] [Python-checkins] r83890 -
	python/branches/py3k/Lib/inspect.py
In-Reply-To: <AANLkTikSeZsW3usOMmMPZ-SASokv1nDgoiydSy_5AQ66@mail.gmail.com>
References: <20100809130535.9F587EE9CA@mail.python.org>
	<AANLkTikSeZsW3usOMmMPZ-SASokv1nDgoiydSy_5AQ66@mail.gmail.com>
Message-ID: <AANLkTinBTuT-pocWqDg=i3mWb4nrtOHxVxgbkZmJQR_D@mail.gmail.com>

2010/8/9 Nick Coghlan <ncoghlan at gmail.com>:
> On Mon, Aug 9, 2010 at 11:05 PM, benjamin.peterson
> <python-checkins at python.org> wrote:
>> -if hasattr(sys, '_getframe'):
>> - ? ?currentframe = sys._getframe
>> -else:
>> - ? ?currentframe = lambda _=None: None
>> +def currentframe():
>> + ? ?"""Return the frame or the caller or None if this is not possible."""
>> + ? ?return sys._getframe(1) if hasattr(sys, "_getframe") else None
>
> It isn't hugely important, but with sys._getframe() unlikely to appear
> during runtime, the following may make more sense:
>
> if hasattr(sys, '_getframe'):
> ? ?def currentframe():
> ? ? ? ?return sys._getframe(1)
> else:
> ? ?def currentframe():
> ? ? ? ?pass
> currentframe.__doc__ = "Return the frame of the caller or None if this
> is not possible."

I considered that but found the docstring thing ugly.

>
> (Oh, and there's a typo in the docstring...)

Thanks.


-- 
Regards,
Benjamin

From alexander.belopolsky at gmail.com  Mon Aug  9 18:26:46 2010
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Mon, 9 Aug 2010 12:26:46 -0400
Subject: [Python-Dev] [Python-checkins] r83890 -
	python/branches/py3k/Lib/inspect.py
In-Reply-To: <AANLkTinBTuT-pocWqDg=i3mWb4nrtOHxVxgbkZmJQR_D@mail.gmail.com>
References: <20100809130535.9F587EE9CA@mail.python.org>
	<AANLkTikSeZsW3usOMmMPZ-SASokv1nDgoiydSy_5AQ66@mail.gmail.com>
	<AANLkTinBTuT-pocWqDg=i3mWb4nrtOHxVxgbkZmJQR_D@mail.gmail.com>
Message-ID: <AANLkTinYgdB4WbxOOAAw8xA-5T_5LjHDqqm5VdX6fasz@mail.gmail.com>

On Mon, Aug 9, 2010 at 11:48 AM, Benjamin Peterson <benjamin at python.org> wrote:
> 2010/8/9 Nick Coghlan <ncoghlan at gmail.com>:
>> On Mon, Aug 9, 2010 at 11:05 PM, benjamin.peterson
>> <python-checkins at python.org> wrote:
>>> -if hasattr(sys, '_getframe'):
>>> - ? ?currentframe = sys._getframe
>>> -else:
>>> - ? ?currentframe = lambda _=None: None
>>> +def currentframe():
>>> + ? ?"""Return the frame or the caller or None if this is not possible."""
>>> + ? ?return sys._getframe(1) if hasattr(sys, "_getframe") else None
>>
>> It isn't hugely important, but with sys._getframe() unlikely to appear
>> during runtime, the following may make more sense:
>>
>> if hasattr(sys, '_getframe'):
>> ? ?def currentframe():
>> ? ? ? ?return sys._getframe(1)
>> else:
>> ? ?def currentframe():
>> ? ? ? ?pass
>> currentframe.__doc__ = "Return the frame of the caller or None if this
>> is not possible."
>
> I considered that but found the docstring thing ugly.
>

I think I have a brighter color for this bikeshed:

 if hasattr(sys, '_getframe'):
? ?def currentframe():
        "Return the frame of the caller."
        ..
else:
   def currentframe():
        "Not supported on this platform.  Always returns None."
        ..

The working version's docstring may also explain that it may return
None on some platforms.

From sturla at molden.no  Mon Aug  9 20:47:23 2010
From: sturla at molden.no (Sturla Molden)
Date: Mon, 9 Aug 2010 20:47:23 +0200
Subject: [Python-Dev] mingw support?
In-Reply-To: <AANLkTi=dc=0brYo34=xaU6D9wH97eB_tTN=b=FBNjLNh@mail.gmail.com>
References: <20100807195541.GA13990@laptop.gs> <i3n225$osp$1@dough.gmane.org>
	<AANLkTi=dc=0brYo34=xaU6D9wH97eB_tTN=b=FBNjLNh@mail.gmail.com>
Message-ID: <9f2ea5ad00140f45fdf639eb0b234aea.squirrel@webmail.uio.no>

> Terry Reedy:

>    MingW has become less attractive in recent years by the difficulty
> in downloading and installing a current version and finding out how to
> do so. Some projects have moved on to the TDM packaging of MingW.
>
> http://tdm-gcc.tdragon.net/


MinGW has become a mess. Equation.com used to have a decent installer, but
at some point they started to ship mingw builds with a Trojan. TDM looks
OK for now.

Building 32-bit Python extension works with MinGW. 64-bit extensions are
not possible due to lacking import libraries (no libmsvcr90.a and
libpython26.a for amd64). It is not possible to build Python with mingw,
only extensions.

I think it is possible to build Python with Microsoft's SDK compiler, as
it has nmake. The latest is Windows 7 SDK for .NET 4, but we need the
version for .NET 3.5 to maintain CRT compatibility with current Python
releases.

Python's distutils do not work with the SDK compiler, only Visual Studio.
Building Python extensions with the SDK compiler is not as easy as it
could (or should) be.

One advantage of mingw for scientific programmers (which a frequent users
of Python) is the gfortran compiler. Although it is not as capable as
Absoft or Intel Fortran, it is still decent and can be used with f2py.
This makes the lack of 64-bit support for Python extensions with mingw
particularly annoying. Microsoft's SDK does not have a Fortran compiler,
and commercial versions are very expensive (though I prefer to pay for
Absoft anyway).

I do not wish for a complete build process for mingw. But support for
64-bit exensions with mingw and distutils support for Microsoft's SDK
compiler would be nice.

Sturla


From casevh at gmail.com  Mon Aug  9 22:04:26 2010
From: casevh at gmail.com (Case Vanhorsen)
Date: Mon, 9 Aug 2010 13:04:26 -0700
Subject: [Python-Dev] mingw support?
In-Reply-To: <9f2ea5ad00140f45fdf639eb0b234aea.squirrel@webmail.uio.no>
References: <20100807195541.GA13990@laptop.gs> <i3n225$osp$1@dough.gmane.org>
	<AANLkTi=dc=0brYo34=xaU6D9wH97eB_tTN=b=FBNjLNh@mail.gmail.com>
	<9f2ea5ad00140f45fdf639eb0b234aea.squirrel@webmail.uio.no>
Message-ID: <AANLkTin_hwtAc34EecJ3whNdFxwGbYbxjGFhvUFy4d5F@mail.gmail.com>

On Mon, Aug 9, 2010 at 11:47 AM, Sturla Molden <sturla at molden.no> wrote:
>> Terry Reedy:
>
>> ? ?MingW has become less attractive in recent years by the difficulty
>> in downloading and installing a current version and finding out how to
>> do so. Some projects have moved on to the TDM packaging of MingW.
>>
>> http://tdm-gcc.tdragon.net/
>
>
> MinGW has become a mess. Equation.com used to have a decent installer, but
> at some point they started to ship mingw builds with a Trojan. TDM looks
> OK for now.
>
> Building 32-bit Python extension works with MinGW. 64-bit extensions are
> not possible due to lacking import libraries (no libmsvcr90.a and
> libpython26.a for amd64). It is not possible to build Python with mingw,
> only extensions.
>
> I think it is possible to build Python with Microsoft's SDK compiler, as
> it has nmake. The latest is Windows 7 SDK for .NET 4, but we need the
> version for .NET 3.5 to maintain CRT compatibility with current Python
> releases.
>
> Python's distutils do not work with the SDK compiler, only Visual Studio.
> Building Python extensions with the SDK compiler is not as easy as it
> could (or should) be.

Based on hints here:

http://docs.python.org/distutils/apiref.html?highlight=sdk#module-distutils.msvccompiler

I've been able to build GMPY and MPIR using just SDK compiler. For an
example, see

http://code.google.com/p/gmpy/source/browse/trunk/win_x64_sdk_build.txt

I agree that it should be easier but it is possible.

casevh
>
> One advantage of mingw for scientific programmers (which a frequent users
> of Python) is the gfortran compiler. Although it is not as capable as
> Absoft or Intel Fortran, it is still decent and can be used with f2py.
> This makes the lack of 64-bit support for Python extensions with mingw
> particularly annoying. Microsoft's SDK does not have a Fortran compiler,
> and commercial versions are very expensive (though I prefer to pay for
> Absoft anyway).
>
> I do not wish for a complete build process for mingw. But support for
> 64-bit exensions with mingw and distutils support for Microsoft's SDK
> compiler would be nice.
>
> Sturla
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/casevh%40gmail.com
>

From solipsis at pitrou.net  Mon Aug  9 22:44:39 2010
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 9 Aug 2010 22:44:39 +0200
Subject: [Python-Dev] r83869 - in python/branches/py3k:
 Doc/library/socket.rst Doc/whatsnew/3.2.rst Lib/ssl.py
 Lib/test/test_socket.py Misc/NEWS Modules/socketmodule.c
References: <20100808232450.7660BEEA37@mail.python.org>
	<20100809014824.3b4b713f@pitrou.net>
	<4C5F4382.8040103@trueblade.com>
Message-ID: <20100809224439.57452977@pitrou.net>

On Sun, 08 Aug 2010 19:53:38 -0400
Eric Smith <eric at trueblade.com> wrote:

> On 8/8/10 7:48 PM, Antoine Pitrou wrote:
> > On Mon,  9 Aug 2010 01:24:50 +0200 (CEST)
> > antoine.pitrou<python-checkins at python.org>  wrote:
> >> Author: antoine.pitrou
> >> Date: Mon Aug  9 01:24:50 2010
> >> New Revision: 83869
> >>
> >> Log:
> >> Issue #8524: Add a forget() method to socket objects, so as to put the
> >> socket into the closed state without closing the underlying file
> >> descriptor.
> >
> > Benjamin suggested to call this detach() instead. What do you think?
> 
> detach() is the name I've seen most often for this. For example, that's 
> what MFC uses:
> http://msdn.microsoft.com/en-us/library/7zhdchw8(VS.80).aspx

Thanks. I've done the rename in r83908.

Regards

Antoine.



From martin at v.loewis.de  Mon Aug  9 22:55:40 2010
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 09 Aug 2010 22:55:40 +0200
Subject: [Python-Dev] mingw support?
In-Reply-To: <9f2ea5ad00140f45fdf639eb0b234aea.squirrel@webmail.uio.no>
References: <20100807195541.GA13990@laptop.gs>
	<i3n225$osp$1@dough.gmane.org>	<AANLkTi=dc=0brYo34=xaU6D9wH97eB_tTN=b=FBNjLNh@mail.gmail.com>
	<9f2ea5ad00140f45fdf639eb0b234aea.squirrel@webmail.uio.no>
Message-ID: <4C606B4C.5000408@v.loewis.de>

> Python's distutils do not work with the SDK compiler, only Visual Studio.

That is not true.

Regards,
Martin

From steve at holdenweb.com  Mon Aug  9 23:00:55 2010
From: steve at holdenweb.com (Steve Holden)
Date: Mon, 09 Aug 2010 17:00:55 -0400
Subject: [Python-Dev] mingw support?
In-Reply-To: <9f2ea5ad00140f45fdf639eb0b234aea.squirrel@webmail.uio.no>
References: <20100807195541.GA13990@laptop.gs>
	<i3n225$osp$1@dough.gmane.org>	<AANLkTi=dc=0brYo34=xaU6D9wH97eB_tTN=b=FBNjLNh@mail.gmail.com>
	<9f2ea5ad00140f45fdf639eb0b234aea.squirrel@webmail.uio.no>
Message-ID: <i3pqaf$1bt$1@dough.gmane.org>

On 8/9/2010 2:47 PM, Sturla Molden wrote:
>> Terry Reedy:
[...]
> 
> Python's distutils do not work with the SDK compiler, only Visual Studio.
> Building Python extensions with the SDK compiler is not as easy as it
> could (or should) be.
> 
At one point Mike Fletcher published a patch to make distutils use the
SDK compiler. It would make a lot of sense if it were built in to
distutils as a further compiler choice.

regards
 Steve
-- 
Steve Holden           +1 571 484 6266   +1 800 494 3119
DjangoCon US September 7-9, 2010    http://djangocon.us/
See Python Video!       http://python.mirocommunity.org/
Holden Web LLC                 http://www.holdenweb.com/


From martin at v.loewis.de  Mon Aug  9 23:37:33 2010
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 09 Aug 2010 23:37:33 +0200
Subject: [Python-Dev] mingw support?
In-Reply-To: <i3pqaf$1bt$1@dough.gmane.org>
References: <20100807195541.GA13990@laptop.gs>	<i3n225$osp$1@dough.gmane.org>	<AANLkTi=dc=0brYo34=xaU6D9wH97eB_tTN=b=FBNjLNh@mail.gmail.com>	<9f2ea5ad00140f45fdf639eb0b234aea.squirrel@webmail.uio.no>
	<i3pqaf$1bt$1@dough.gmane.org>
Message-ID: <4C60751D.80804@v.loewis.de>

Am 09.08.2010 23:00, schrieb Steve Holden:
> On 8/9/2010 2:47 PM, Sturla Molden wrote:
>>> Terry Reedy:
> [...]
>>
>> Python's distutils do not work with the SDK compiler, only Visual Studio.
>> Building Python extensions with the SDK compiler is not as easy as it
>> could (or should) be.
>>
> At one point Mike Fletcher published a patch to make distutils use the
> SDK compiler. It would make a lot of sense if it were built in to
> distutils as a further compiler choice.

Please understand that this very choice is there already.

Regards,
Martin

From steve at holdenweb.com  Mon Aug  9 23:52:09 2010
From: steve at holdenweb.com (Steve Holden)
Date: Mon, 09 Aug 2010 17:52:09 -0400
Subject: [Python-Dev] mingw support?
In-Reply-To: <4C60751D.80804@v.loewis.de>
References: <20100807195541.GA13990@laptop.gs>	<i3n225$osp$1@dough.gmane.org>	<AANLkTi=dc=0brYo34=xaU6D9wH97eB_tTN=b=FBNjLNh@mail.gmail.com>	<9f2ea5ad00140f45fdf639eb0b234aea.squirrel@webmail.uio.no>
	<i3pqaf$1bt$1@dough.gmane.org> <4C60751D.80804@v.loewis.de>
Message-ID: <4C607889.3080801@holdenweb.com>

On 8/9/2010 5:37 PM, "Martin v. L?wis" wrote:
> Am 09.08.2010 23:00, schrieb Steve Holden:
>> On 8/9/2010 2:47 PM, Sturla Molden wrote:
>>>> Terry Reedy:
>> [...]
>>>
>>> Python's distutils do not work with the SDK compiler, only Visual Studio.
>>> Building Python extensions with the SDK compiler is not as easy as it
>>> could (or should) be.
>>>
>> At one point Mike Fletcher published a patch to make distutils use the
>> SDK compiler. It would make a lot of sense if it were built in to
>> distutils as a further compiler choice.
> 
> Please understand that this very choice is there already.
> 
That's great. Is that what the documentation refers to when it says

"""
MSVCCompiler will normally choose the right compiler, linker etc. on its
own. To override this choice, the environment variables
DISTUTILS_USE_SDK and MSSdk must be both set. MSSdk indicates that the
current environment has been setup by the SDK?s SetEnv.Cmd script, or
that the environment variables had been registered when the SDK was
installed; DISTUTILS_USE_SDK indicates that the distutils user has made
an explicit choice to override the compiler selection by MSVCCompiler.
"""

That isn't particularly clear to me, but it may be to others more
familiar with building on Windows.

regards
 Steve
-- 
Steve Holden           +1 571 484 6266   +1 800 494 3119
DjangoCon US September 7-9, 2010    http://djangocon.us/
See Python Video!       http://python.mirocommunity.org/
Holden Web LLC                 http://www.holdenweb.com/

From martin at v.loewis.de  Tue Aug 10 00:04:19 2010
From: martin at v.loewis.de (=?windows-1252?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 10 Aug 2010 00:04:19 +0200
Subject: [Python-Dev] mingw support?
In-Reply-To: <4C607889.3080801@holdenweb.com>
References: <20100807195541.GA13990@laptop.gs>	<i3n225$osp$1@dough.gmane.org>	<AANLkTi=dc=0brYo34=xaU6D9wH97eB_tTN=b=FBNjLNh@mail.gmail.com>	<9f2ea5ad00140f45fdf639eb0b234aea.squirrel@webmail.uio.no>
	<i3pqaf$1bt$1@dough.gmane.org> <4C60751D.80804@v.loewis.de>
	<4C607889.3080801@holdenweb.com>
Message-ID: <4C607B63.3070809@v.loewis.de>

>> Please understand that this very choice is there already.
>>
> That's great. Is that what the documentation refers to when it says

Correct.

> That isn't particularly clear to me, but it may be to others more
> familiar with building on Windows.

People familiar with that documentation fragment had no problem making
it work. The problem has rather been that people didn't expect that
to be supported, and didn't try to determine whether it was supported.
If you search for "SDK" in the online documentation, this will
be the only piece that comes up.

Not sure when Mike Fletcher wrote his code - if it is recent, he
surely must have run into the feature while reading the existing
code base.

Regards,
Martin

From sturla at molden.no  Tue Aug 10 00:34:09 2010
From: sturla at molden.no (Sturla Molden)
Date: Tue, 10 Aug 2010 00:34:09 +0200
Subject: [Python-Dev] mingw support?
In-Reply-To: <4C607889.3080801@holdenweb.com>
References: <20100807195541.GA13990@laptop.gs> <i3n225$osp$1@dough.gmane.org>
	<AANLkTi=dc=0brYo34=xaU6D9wH97eB_tTN=b=FBNjLNh@mail.gmail.com>
	<9f2ea5ad00140f45fdf639eb0b234aea.squirrel@webmail.uio.no>
	<i3pqaf$1bt$1@dough.gmane.org> <4C60751D.80804@v.loewis.de>
	<4C607889.3080801@holdenweb.com>
Message-ID: <5a288b8c046260c099b486f40bf345b6.squirrel@webmail.uio.no>


>> Please understand that this very choice is there already.
>>
> That's great. Is that what the documentation refers to when it says
>
> """
> MSVCCompiler will normally choose the right compiler, linker etc. on its
> own. To override this choice, the environment variables
> DISTUTILS_USE_SDK and MSSdk must be both set. MSSdk indicates that the
> current environment has been setup by the SDK?s SetEnv.Cmd script, or
> that the environment variables had been registered when the SDK was
> installed; DISTUTILS_USE_SDK indicates that the distutils user has made
> an explicit choice to override the compiler selection by MSVCCompiler.
> """
>
> That isn't particularly clear to me, but it may be to others more
> familiar with building on Windows.


Ahh...

"MSSdk must be set" typically means we must use the Windows 7 SDK command
prompt.

Without DISTUTILS_USE_SDK, the build fails:


C:\DEVELOPMENT\test-distutils>setup.py build_ext
running build_ext
building 'test' extension
Traceback (most recent call last):
  File "C:\DEVELOPMENT\test-distutils\setup.py", line 6, in <module>
    ext_modules=[Extension('test', ['test.c'])],
  File "C:\Python26\lib\distutils\core.py", line 152, in setup
    dist.run_commands()
  File "C:\Python26\lib\distutils\dist.py", line 975, in run_commands
    self.run_command(cmd)
  File "C:\Python26\lib\distutils\dist.py", line 995, in run_command
    cmd_obj.run()
  File "C:\Python26\lib\distutils\command\build_ext.py", line 340, in run
    self.build_extensions()
  File "C:\Python26\lib\distutils\command\build_ext.py", line 449, in
build_exte
nsions
    self.build_extension(ext)
  File "C:\Python26\lib\distutils\command\build_ext.py", line 499, in
build_exte
nsion
    depends=ext.depends)
  File "C:\Python26\lib\distutils\msvc9compiler.py", line 449, in compile
    self.initialize()
  File "C:\Python26\lib\distutils\msvc9compiler.py", line 359, in initialize
    vc_env = query_vcvarsall(VERSION, plat_spec)
  File "C:\Python26\lib\distutils\msvc9compiler.py", line 275, in
query_vcvarsal
l
    raise ValueError(str(list(result.keys())))
ValueError: [u'path', u'include', u'lib']



Now let's do what the documentations says:

C:\DEVELOPMENT\test-distutils>set DISTUTILS_USE_SDK=1

C:\DEVELOPMENT\test-distutils>setup.py build_ext
running build_ext
building 'test' extension
creating build
creating build\temp.win-amd64-2.6
creating build\temp.win-amd64-2.6\Release
C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\Bin\amd64\cl.exe /c
/nolog
o /Ox /MD /W3 /GS- /DNDEBUG -IC:\Python26\include -IC:\Python26\PC
/Tctest.c /Fo
build\temp.win-amd64-2.6\Release\test.obj
test.c
creating build\lib.win-amd64-2.6
C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\Bin\amd64\link.exe
/DLL /n
ologo /INCREMENTAL:NO /LIBPATH:C:\Python26\libs
/LIBPATH:C:\Python26\PCbuild\amd
64 /EXPORT:inittest build\temp.win-amd64-2.6\Release\test.obj
/OUT:build\lib.win
-amd64-2.6\test.pyd /IMPLIB:build\temp.win-amd64-2.6\Release\test.lib
/MANIFESTF
ILE:build\temp.win-amd64-2.6\Release\test.pyd.manifest
test.obj : warning LNK4197: export 'inittest' specified multiple times;
using fi
rst specification
   Creating library build\temp.win-amd64-2.6\Release\test.lib and object
build\t
emp.win-amd64-2.6\Release\test.exp
C:\Program Files\Microsoft SDKs\Windows\v7.0\Bin\x64\mt.exe -nologo
-manifest bu
ild\temp.win-amd64-2.6\Release\test.pyd.manifest
-outputresource:build\lib.win-a
md64-2.6\test.pyd;2


:-D


Sturla


From sturla at molden.no  Tue Aug 10 00:37:39 2010
From: sturla at molden.no (Sturla Molden)
Date: Tue, 10 Aug 2010 00:37:39 +0200
Subject: [Python-Dev] mingw support?
In-Reply-To: <4C60751D.80804@v.loewis.de>
References: <20100807195541.GA13990@laptop.gs> <i3n225$osp$1@dough.gmane.org>
	<AANLkTi=dc=0brYo34=xaU6D9wH97eB_tTN=b=FBNjLNh@mail.gmail.com>
	<9f2ea5ad00140f45fdf639eb0b234aea.squirrel@webmail.uio.no>
	<i3pqaf$1bt$1@dough.gmane.org> <4C60751D.80804@v.loewis.de>
Message-ID: <54fe1df4bcfb721bae113a04d193b7b9.squirrel@webmail.uio.no>


>> At one point Mike Fletcher published a patch to make distutils use the
>> SDK compiler. It would make a lot of sense if it were built in to
>> distutils as a further compiler choice.
>
> Please understand that this very choice is there already.
>

Yes you are right. I did not know about DISTUTILS_USE_SDK.

Sturla


From tjreedy at udel.edu  Tue Aug 10 00:55:29 2010
From: tjreedy at udel.edu (Terry Reedy)
Date: Mon, 09 Aug 2010 18:55:29 -0400
Subject: [Python-Dev] mingw support?
In-Reply-To: <9f2ea5ad00140f45fdf639eb0b234aea.squirrel@webmail.uio.no>
References: <20100807195541.GA13990@laptop.gs>
	<i3n225$osp$1@dough.gmane.org>	<AANLkTi=dc=0brYo34=xaU6D9wH97eB_tTN=b=FBNjLNh@mail.gmail.com>
	<9f2ea5ad00140f45fdf639eb0b234aea.squirrel@webmail.uio.no>
Message-ID: <i3q110$ncr$1@dough.gmane.org>

On 8/9/2010 2:47 PM, Sturla Molden wrote:
>> Terry Reedy:
>
>>     MingW has become less attractive in recent years by the difficulty
>> in downloading and installing a current version and finding out how to
>> do so. Some projects have moved on to the TDM packaging of MingW.
>>
>> http://tdm-gcc.tdragon.net/

Someone else deserves credit for writing that and giving that link ;-)

-- 
Terry Jan Reedy


From ncoghlan at gmail.com  Tue Aug 10 04:47:44 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 10 Aug 2010 12:47:44 +1000
Subject: [Python-Dev] [Python-checkins] r83893 -
	python/branches/release27-maint/Misc/ACKS
In-Reply-To: <20100809161007.81567EE9F7@mail.python.org>
References: <20100809161007.81567EE9F7@mail.python.org>
Message-ID: <AANLkTimWa_M_Zzt+QJEkTvr7ijY9yCYsR6afVUci1z1x@mail.gmail.com>

On Tue, Aug 10, 2010 at 2:10 AM, alexander.belopolsky
<python-checkins at python.org> wrote:
> +PS: In the standard Python distribution, this file is encoded in UTF-8
> +and the list is in rough alphabetical order by last names.
>
> ?David Abrahams
> ?Jim Ahlstrom
> @@ -28,6 +29,7 @@
> ??ric Araujo
> ?Jason Asbahr
> ?David Ascher
> +Peter ?strand

>From my recollection of the discussion when Peter was added, the first
character in his last name actually sorts after Z (despite its
resemblance to an A).

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From benjamin at python.org  Tue Aug 10 04:53:39 2010
From: benjamin at python.org (Benjamin Peterson)
Date: Mon, 9 Aug 2010 21:53:39 -0500
Subject: [Python-Dev] [Python-checkins] r83893 -
	python/branches/release27-maint/Misc/ACKS
In-Reply-To: <AANLkTimWa_M_Zzt+QJEkTvr7ijY9yCYsR6afVUci1z1x@mail.gmail.com>
References: <20100809161007.81567EE9F7@mail.python.org>
	<AANLkTimWa_M_Zzt+QJEkTvr7ijY9yCYsR6afVUci1z1x@mail.gmail.com>
Message-ID: <AANLkTin5yFjNMCBYxV2+dMsNdB95bt_z3zOiVdG=jQJr@mail.gmail.com>

2010/8/9 Nick Coghlan <ncoghlan at gmail.com>:
> On Tue, Aug 10, 2010 at 2:10 AM, alexander.belopolsky
> <python-checkins at python.org> wrote:
>> +PS: In the standard Python distribution, this file is encoded in UTF-8
>> +and the list is in rough alphabetical order by last names.
>>
>> ?David Abrahams
>> ?Jim Ahlstrom
>> @@ -28,6 +29,7 @@
>> ??ric Araujo
>> ?Jason Asbahr
>> ?David Ascher
>> +Peter ?strand
>
> >From my recollection of the discussion when Peter was added, the first
> character in his last name actually sorts after Z (despite its
> resemblance to an A).

This is correct. Don't think of ? as a kind of "A". It's its own
letter, which sorts after Z in Swedish.



-- 
Regards,
Benjamin

From alexander.belopolsky at gmail.com  Tue Aug 10 05:24:49 2010
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Mon, 9 Aug 2010 23:24:49 -0400
Subject: [Python-Dev] [Python-checkins] r83893 -
	python/branches/release27-maint/Misc/ACKS
In-Reply-To: <AANLkTin5yFjNMCBYxV2+dMsNdB95bt_z3zOiVdG=jQJr@mail.gmail.com>
References: <20100809161007.81567EE9F7@mail.python.org>
	<AANLkTimWa_M_Zzt+QJEkTvr7ijY9yCYsR6afVUci1z1x@mail.gmail.com>
	<AANLkTin5yFjNMCBYxV2+dMsNdB95bt_z3zOiVdG=jQJr@mail.gmail.com>
Message-ID: <14CCDAF6-743E-4A95-9D44-9A119855F476@gmail.com>

Was it on IRC? I do remember discussion, but forgot the answer. :(

Do you agree that ACKS should be the same in the active branches? I'll  
fix the order when I merge the lists.



On Aug 9, 2010, at 10:53 PM, Benjamin Peterson <benjamin at python.org>  
wrote:

> 2010/8/9 Nick Coghlan <ncoghlan at gmail.com>:
>> On Tue, Aug 10, 2010 at 2:10 AM, alexander.belopolsky
>> <python-checkins at python.org> wrote:
>>> +PS: In the standard Python distribution, this file is encoded in  
>>> UTF-8
>>> +and the list is in rough alphabetical order by last names.
>>>
>>>  David Abrahams
>>>  Jim Ahlstrom
>>> @@ -28,6 +29,7 @@
>>>  ?ric Araujo
>>>  Jason Asbahr
>>>  David Ascher
>>> +Peter ?strand
>>
>>> From my recollection of the discussion when Peter was added, the  
>>> first
>> character in his last name actually sorts after Z (despite its
>> resemblance to an A).
>
> This is correct. Don't think of ? as a kind of "A". It's its own
> letter, which sorts after Z in Swedish.
>
>
>
> -- 
> Regards,
> Benjamin
> _______________________________________________
> Python-checkins mailing list
> Python-checkins at python.org
> http://mail.python.org/mailman/listinfo/python-checkins

From ncoghlan at gmail.com  Tue Aug 10 05:32:36 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 10 Aug 2010 13:32:36 +1000
Subject: [Python-Dev] [Python-checkins] r83893 -
	python/branches/release27-maint/Misc/ACKS
In-Reply-To: <14CCDAF6-743E-4A95-9D44-9A119855F476@gmail.com>
References: <20100809161007.81567EE9F7@mail.python.org>
	<AANLkTimWa_M_Zzt+QJEkTvr7ijY9yCYsR6afVUci1z1x@mail.gmail.com>
	<AANLkTin5yFjNMCBYxV2+dMsNdB95bt_z3zOiVdG=jQJr@mail.gmail.com>
	<14CCDAF6-743E-4A95-9D44-9A119855F476@gmail.com>
Message-ID: <AANLkTi=64xPHwKCYi0AHa5rT9R4XcTn7wobWvS=0qeuK@mail.gmail.com>

On Tue, Aug 10, 2010 at 1:24 PM, Alexander Belopolsky
<alexander.belopolsky at gmail.com> wrote:
> Was it on IRC? I do remember discussion, but forgot the answer. :(

python-dev or python-checkins I think, but I don't really remember.
(Not IRC though, as I only very rarely drop in on the channel)

> Do you agree that ACKS should be the same in the active branches? I'll fix
> the order when I merge the lists.

The most important one to keep up to date is the one for the main
development branch, since that should be a superset of all the others.
The maintenance branches will naturally be missing new contributors
(aside from those contributing bug fixes for that branch), and that's
OK.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From alexander.belopolsky at gmail.com  Tue Aug 10 05:49:39 2010
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Mon, 9 Aug 2010 23:49:39 -0400
Subject: [Python-Dev] [Python-checkins] r83893 -
	python/branches/release27-maint/Misc/ACKS
In-Reply-To: <AANLkTi=64xPHwKCYi0AHa5rT9R4XcTn7wobWvS=0qeuK@mail.gmail.com>
References: <20100809161007.81567EE9F7@mail.python.org>
	<AANLkTimWa_M_Zzt+QJEkTvr7ijY9yCYsR6afVUci1z1x@mail.gmail.com>
	<AANLkTin5yFjNMCBYxV2+dMsNdB95bt_z3zOiVdG=jQJr@mail.gmail.com>
	<14CCDAF6-743E-4A95-9D44-9A119855F476@gmail.com>
	<AANLkTi=64xPHwKCYi0AHa5rT9R4XcTn7wobWvS=0qeuK@mail.gmail.com>
Message-ID: <AANLkTinMUkwe_RWU7WonrGp2OdM_TrXb4ZRyt+hcfxnc@mail.gmail.com>

On Mon, Aug 9, 2010 at 11:32 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On Tue, Aug 10, 2010 at 1:24 PM, Alexander Belopolsky
> <alexander.belopolsky at gmail.com> wrote:
>> Was it on IRC? I do remember discussion, but forgot the answer. :(
>
> python-dev or python-checkins I think, but I don't really remember.
> (Not IRC though, as I only very rarely drop in on the channel)
>
I'll search the archives.  My reasoning was that ? in ?strand was the
same as ? in ?ngstr?m.  Webster's dictionary (1992 edition that was on
my bookshelf) has ?ngstr?m (Anders Jonas) between angstrom (the unit)
and Anguilla (an island).

>> Do you agree that ACKS should be the same in the active branches? I'll fix
>> the order when I merge the lists.
>
> The most important one to keep up to date is the one for the main
> development branch, since that should be a superset of all the others.
> The maintenance branches will naturally be missing new contributors
> (aside from those contributing bug fixes for that branch), and that's
> OK.
>

As I mentioned in a tracker comment, it may be useful to sync the
lists between the main and development branches to avoid svnmerge
conflicts.   I think I've seen some names missing from the main branch
which exist in maintenance ones.

From martin at v.loewis.de  Tue Aug 10 07:18:32 2010
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 10 Aug 2010 07:18:32 +0200
Subject: [Python-Dev] [Python-checkins] r83893
	-	python/branches/release27-maint/Misc/ACKS
In-Reply-To: <AANLkTimWa_M_Zzt+QJEkTvr7ijY9yCYsR6afVUci1z1x@mail.gmail.com>
References: <20100809161007.81567EE9F7@mail.python.org>
	<AANLkTimWa_M_Zzt+QJEkTvr7ijY9yCYsR6afVUci1z1x@mail.gmail.com>
Message-ID: <4C60E128.8050907@v.loewis.de>

Am 10.08.2010 04:47, schrieb Nick Coghlan:
> On Tue, Aug 10, 2010 at 2:10 AM, alexander.belopolsky
> <python-checkins at python.org> wrote:
>> +PS: In the standard Python distribution, this file is encoded in UTF-8
>> +and the list is in rough alphabetical order by last names.
>>
>>  David Abrahams
>>  Jim Ahlstrom
>> @@ -28,6 +29,7 @@
>>  ?ric Araujo
>>  Jason Asbahr
>>  David Ascher
>> +Peter ?strand
> 
>>From my recollection of the discussion when Peter was added, the first
> character in his last name actually sorts after Z (despite its
> resemblance to an A).

That's why it says "rough" alphabetical order. Putting it into either
place sounds reasonable - we can just expect people to change it forth
and back.

Regards,
Martin

From martin at v.loewis.de  Tue Aug 10 07:53:51 2010
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 10 Aug 2010 07:53:51 +0200
Subject: [Python-Dev] [Python-checkins] r83893
	-	python/branches/release27-maint/Misc/ACKS
In-Reply-To: <AANLkTinMUkwe_RWU7WonrGp2OdM_TrXb4ZRyt+hcfxnc@mail.gmail.com>
References: <20100809161007.81567EE9F7@mail.python.org>	<AANLkTimWa_M_Zzt+QJEkTvr7ijY9yCYsR6afVUci1z1x@mail.gmail.com>	<AANLkTin5yFjNMCBYxV2+dMsNdB95bt_z3zOiVdG=jQJr@mail.gmail.com>	<14CCDAF6-743E-4A95-9D44-9A119855F476@gmail.com>	<AANLkTi=64xPHwKCYi0AHa5rT9R4XcTn7wobWvS=0qeuK@mail.gmail.com>
	<AANLkTinMUkwe_RWU7WonrGp2OdM_TrXb4ZRyt+hcfxnc@mail.gmail.com>
Message-ID: <4C60E96F.2090402@v.loewis.de>

Am 10.08.2010 05:49, schrieb Alexander Belopolsky:
> On Mon, Aug 9, 2010 at 11:32 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> On Tue, Aug 10, 2010 at 1:24 PM, Alexander Belopolsky
>> <alexander.belopolsky at gmail.com> wrote:
>>> Was it on IRC? I do remember discussion, but forgot the answer. :(
>>
>> python-dev or python-checkins I think, but I don't really remember.
>> (Not IRC though, as I only very rarely drop in on the channel)
>>
> I'll search the archives.  My reasoning was that ? in ?strand was the
> same as ? in ?ngstr?m.  Webster's dictionary (1992 edition that was on
> my bookshelf) has ?ngstr?m (Anders Jonas) between angstrom (the unit)
> and Anguilla (an island).

People need to recognize that any kind of reference is really irrelevant
here. There is no "right" order that is better than any other "right"
order. I'd personally object to any English language dictionary telling
me how my name sorts in the alphabet.

(and yes, I do think it's "wrong" that it got sorted after Lyngvig -
in Germany, we put the ? as if it was "oe" - unlike the Swedes, which
put the very same letter after the rest of the alphabet. So the
? in Chrigstr?m sorts in a different way than the ? in L?wis. If I move
to Sweden, the file would have to change :-)

Regards,
Martin

From stephen at xemacs.org  Tue Aug 10 10:00:22 2010
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Tue, 10 Aug 2010 17:00:22 +0900
Subject: [Python-Dev] [Python-checkins] r83893
	-	python/branches/release27-maint/Misc/ACKS
In-Reply-To: <AANLkTin5yFjNMCBYxV2+dMsNdB95bt_z3zOiVdG=jQJr@mail.gmail.com>
References: <20100809161007.81567EE9F7@mail.python.org>
	<AANLkTimWa_M_Zzt+QJEkTvr7ijY9yCYsR6afVUci1z1x@mail.gmail.com>
	<AANLkTin5yFjNMCBYxV2+dMsNdB95bt_z3zOiVdG=jQJr@mail.gmail.com>
Message-ID: <874of2ew2x.fsf@uwakimon.sk.tsukuba.ac.jp>

Benjamin Peterson writes:
 > 2010/8/9 Nick Coghlan <ncoghlan at gmail.com>:
 > > On Tue, Aug 10, 2010 at 2:10 AM, alexander.belopolsky
 > > <python-checkins at python.org> wrote:
 > >> +PS: In the standard Python distribution, this file is encoded
 > >> in UTF-8 +and the list is in rough alphabetical order by last
 > >> names.
 > >>
 > >> ?David Abrahams
 > >> ?Jim Ahlstrom
 > >> @@ -28,6 +29,7 @@
 > >> ??ric Araujo
 > >> ?Jason Asbahr
 > >> ?David Ascher
 > >> +Peter ?strand
 > > From my recollection of the discussion when Peter was added, the
 > > >first
 > > character in his last name actually sorts after Z (despite its
 > > resemblance to an A).
 > This is correct. Don't think of ? as a kind of "A". It's its own
 > letter, which sorts after Z in Swedish.

That's true, but IIRC there are a fairly large number of letters where
different languages collate them in different positions.

Is it worth actually asking appropriate humans to think about this, or
would it be better to use Unicode code point order for simplicity?

From ronaldoussoren at mac.com  Tue Aug 10 13:27:38 2010
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Tue, 10 Aug 2010 13:27:38 +0200
Subject: [Python-Dev] Adding a token
In-Reply-To: <4C5E2F7D.5080203@canterbury.ac.nz>
References: <4C5E0B64.4060602@canterbury.ac.nz>
	<AANLkTim3Ay4tM=uvdjh0f0JYf8xP+wca7yV60_Hw=bVZ@mail.gmail.com>
	<4C5E19E4.9060402@canterbury.ac.nz> <4C5E2F7D.5080203@canterbury.ac.nz>
Message-ID: <E1F8EB50-708A-4BDB-88ED-3B45F34DB06E@mac.com>


On 8 Aug, 2010, at 6:15, Greg Ewing wrote:

> Aaargh, I think I've found out what the problem is.
> 
> I'm using framework builds on MacOSX. I have two experimental
> builds of Python 3.1 around, plus a standard one installed in
> /Library. It's picking up the version of Python.framework in
> /Library/Frameworks instead of the one in the local build
> directory that python.exe was explicitly linked with.

Check the RUNPY definition in the Makefile, you should start python.exe using

DYLD_FRAMEWORK_PATH=$PWD ./python.exe

(Assuming your running from the build directory, adjusting this for other situations should be easy)

> 
> Now I'm confused about why my *other* experimental build
> worked -- the one I've been using for yield-from and codef --
> because it should have suffered from the same problem. And
> when I tried to use it again just now, it did indeed not work.
> 
> Does anyone know if there's a way to tell Apple's linker to
> use a framework from a specific location and not go looking
> anywhere else?

Use the '--with-framework-name' option to configure, this enables you to build the framework with an alternate name and therefore have two framework installs side-by-side.

I use this to have a regular python build as well as a --with-pydebug build.

Ronald
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3567 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100810/7ebe643d/attachment.bin>

From benjamin at python.org  Tue Aug 10 15:13:13 2010
From: benjamin at python.org (Benjamin Peterson)
Date: Tue, 10 Aug 2010 08:13:13 -0500
Subject: [Python-Dev] [Python-checkins] r83893 -
	python/branches/release27-maint/Misc/ACKS
In-Reply-To: <874of2ew2x.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <20100809161007.81567EE9F7@mail.python.org>
	<AANLkTimWa_M_Zzt+QJEkTvr7ijY9yCYsR6afVUci1z1x@mail.gmail.com>
	<AANLkTin5yFjNMCBYxV2+dMsNdB95bt_z3zOiVdG=jQJr@mail.gmail.com>
	<874of2ew2x.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <AANLkTimeKq6H9qh3=c1PpbgC8k0H12sFHze3DBE-72qu@mail.gmail.com>

2010/8/10 Stephen J. Turnbull <stephen at xemacs.org>:
> Benjamin Peterson writes:
> ?> 2010/8/9 Nick Coghlan <ncoghlan at gmail.com>:
> ?> > On Tue, Aug 10, 2010 at 2:10 AM, alexander.belopolsky
> ?> > <python-checkins at python.org> wrote:
> ?> >> +PS: In the standard Python distribution, this file is encoded
> ?> >> in UTF-8 +and the list is in rough alphabetical order by last
> ?> >> names.
> ?> >>
> ?> >> ?David Abrahams
> ?> >> ?Jim Ahlstrom
> ?> >> @@ -28,6 +29,7 @@
> ?> >> ??ric Araujo
> ?> >> ?Jason Asbahr
> ?> >> ?David Ascher
> ?> >> +Peter ?strand
> ?> > From my recollection of the discussion when Peter was added, the
> ?> > >first
> ?> > character in his last name actually sorts after Z (despite its
> ?> > resemblance to an A).
> ?> This is correct. Don't think of ? as a kind of "A". It's its own
> ?> letter, which sorts after Z in Swedish.
>
> That's true, but IIRC there are a fairly large number of letters where
> different languages collate them in different positions.
>
> Is it worth actually asking appropriate humans to think about this, or
> would it be better to use Unicode code point order for simplicity?

I think it's largely a unimportant discussion. If people have an
opinion of where their name should appear, they can by all means
change it. However, "rough" is probably as best as it'll ever get.



-- 
Regards,
Benjamin

From status at bugs.python.org  Tue Aug 10 15:39:15 2010
From: status at bugs.python.org (Python tracker)
Date: Tue, 10 Aug 2010 15:39:15 +0200 (CEST)
Subject: [Python-Dev] Summary of Python tracker Issues
Message-ID: <20100810133915.B735578173@psf.upfronthosting.co.za>


ACTIVITY SUMMARY (2010-08-01 - 2010-08-07)
Python tracker at http://bugs.python.org/

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

Issues stats:
  open    2640 (+35)
  closed 18679 (+194)
  total  21319 (+57)

Open issues with patches: 1112 


Issues opened (35)
==================

#8821: Range check on unicode repr
http://bugs.python.org/issue8821  reopened by pitrou

#8959: WINFUNCTYPE wrapped ctypes callbacks not functioning correctly
http://bugs.python.org/issue8959  reopened by brian.curtin

#9323: trace.py bug with the main file being traced
http://bugs.python.org/issue9323  reopened by belopolsky

#9446: urllib2 tests fail when offline
http://bugs.python.org/issue9446  opened by guandalino

#9453: pulldom.SAX2DOM Doesn't support processing instructions before
http://bugs.python.org/issue9453  opened by mark.smith

#9456: Apparent memory leak in PC/bdist_wininst/install.c
http://bugs.python.org/issue9456  opened by Zachary.Blair

#9458: xml.etree.ElementTree.ElementTree.write(): encoding handling p
http://bugs.python.org/issue9458  opened by kune

#9495: argparse unittest tracebacks are confusing if an error is rais
http://bugs.python.org/issue9495  opened by r.david.murray

#9499: Python C/API Execution namespace undocumented. (patch included
http://bugs.python.org/issue9499  opened by ideasman42

#9500: urllib2: Content-Encoding
http://bugs.python.org/issue9500  opened by guest

#9501: Logging shutdown regressions with weakrefs
http://bugs.python.org/issue9501  opened by gz

#9503: print statement hangs Windows service
http://bugs.python.org/issue9503  opened by rgpitts

#9504: signal.signal/signal.alarm not working as expected
http://bugs.python.org/issue9504  opened by alanwilter

#9506: sqlite3 mogrify - return query string
http://bugs.python.org/issue9506  opened by goatbar

#9508: python3.2 reversal of distutils reintrocud macos9 support
http://bugs.python.org/issue9508  opened by ronaldoussoren

#9509: argparse FileType raises ugly exception for missing file
http://bugs.python.org/issue9509  opened by doughellmann

#9511: CharacterEncoderError when reading from sys.stdin from piped i
http://bugs.python.org/issue9511  opened by pbos

#9512: logging.handlers.RotatingFileHandler - mode argument not respe
http://bugs.python.org/issue9512  opened by fridrik

#9514: platform.linux_distribution() under Ubuntu returns ('debian', 
http://bugs.python.org/issue9514  opened by pitrou

#9516: sysconfig: $MACOSX_DEPLOYMENT_TARGET mismatch: now "10.3" but 
http://bugs.python.org/issue9516  opened by srid

#9517: Make test.script_helper more comprehensive, and use it in the 
http://bugs.python.org/issue9517  opened by pitrou

#9518: PyModuleDef_HEAD_INIT does not explicitly initialize all field
http://bugs.python.org/issue9518  opened by dmalcolm

#9520: Add Patricia Trie high performance container
http://bugs.python.org/issue9520  opened by dmtr

#9521: xml.etree.ElementTree strips XML declaration and procesing ins
http://bugs.python.org/issue9521  opened by mark

#9522: xml.etree.ElementTree forgets the encoding
http://bugs.python.org/issue9522  opened by mark

#9523: Improve dbm module
http://bugs.python.org/issue9523  opened by ysj.ray

#9524: Document CTRL_C_EVENT and CTRL_BREAK_EVENT usage on Windows
http://bugs.python.org/issue9524  opened by valgog

#9527: Add aware local time support to datetime module
http://bugs.python.org/issue9527  opened by belopolsky

#9528: Add pure Python implementation of time module to CPython
http://bugs.python.org/issue9528  opened by belopolsky

#9529: Converge re.findall and re.finditer
http://bugs.python.org/issue9529  opened by MizardX

#9530: integer undefined behaviors
http://bugs.python.org/issue9530  opened by regehr

#9532: pipe.read hang, when calling commands.getstatusoutput in multi
http://bugs.python.org/issue9532  opened by denny

#9533: metaclass can't derive from ABC
http://bugs.python.org/issue9533  opened by roalddevries

#9535: Pending signals are inherited by child processes
http://bugs.python.org/issue9535  opened by gdb

#9536: defaultdict doc makes incorrect reference to __missing__ metho
http://bugs.python.org/issue9536  opened by jjposner



Recent issues with no replies (15)
==================================

#9535: Pending signals are inherited by child processes
http://bugs.python.org/issue9535

#9533: metaclass can't derive from ABC
http://bugs.python.org/issue9533

#9523: Improve dbm module
http://bugs.python.org/issue9523

#9521: xml.etree.ElementTree strips XML declaration and procesing ins
http://bugs.python.org/issue9521

#9518: PyModuleDef_HEAD_INIT does not explicitly initialize all field
http://bugs.python.org/issue9518

#9509: argparse FileType raises ugly exception for missing file
http://bugs.python.org/issue9509

#9508: python3.2 reversal of distutils reintrocud macos9 support
http://bugs.python.org/issue9508

#9504: signal.signal/signal.alarm not working as expected
http://bugs.python.org/issue9504

#9499: Python C/API Execution namespace undocumented. (patch included
http://bugs.python.org/issue9499

#9456: Apparent memory leak in PC/bdist_wininst/install.c
http://bugs.python.org/issue9456

#9446: urllib2 tests fail when offline
http://bugs.python.org/issue9446

#9437: test_distutils failure with -m32
http://bugs.python.org/issue9437

#9436: test_sysconfig failure
http://bugs.python.org/issue9436

#9435: test_distutils fails without zlib
http://bugs.python.org/issue9435

#9420: gdbm with /usr/include/ndbm.h
http://bugs.python.org/issue9420



Issues waiting for review (15)
==============================

#1474680: pickling files works with protocol=2.
http://bugs.python.org/issue1474680

#754016: urlparse goes wrong with IP:port without scheme
http://bugs.python.org/issue754016

#1553375: Add traceback.print_full_exception()
http://bugs.python.org/issue1553375

#1170: shlex have problems with parsing unicode
http://bugs.python.org/issue1170

#1187: pipe fd handling issues in subprocess.py on POSIX
http://bugs.python.org/issue1187

#1274: doctest fails to run file based tests with 8bit paths
http://bugs.python.org/issue1274

#1343: XMLGenerator: nice <empty/> elements
http://bugs.python.org/issue1343

#1598: unexpected response in imaplib
http://bugs.python.org/issue1598

#1684: CGIHTTPServer does not chdir prior to executing the CGI script
http://bugs.python.org/issue1684

#1812: doctest _load_testfile function -- newline handling seems inco
http://bugs.python.org/issue1812

#1856: shutdown (exit) can hang or segfault with daemon threads runni
http://bugs.python.org/issue1856

#1978: Python(2.5.1) will be crashed when i use _ssl module in multi-
http://bugs.python.org/issue1978

#2090: __import__ with fromlist=
http://bugs.python.org/issue2090

#2118: smtplib.SMTP() raises socket.error rather than SMTPConnectErro
http://bugs.python.org/issue2118

#2134: function generate_tokens at tokenize.py yields wrong token for
http://bugs.python.org/issue2134



Top issues most discussed (10)
==============================

#9079: Make gettimeofday available in time module
http://bugs.python.org/issue9079  42 msgs

#2736: datetime needs an "epoch" method
http://bugs.python.org/issue2736  35 msgs

#1812: doctest _load_testfile function -- newline handling seems inco
http://bugs.python.org/issue1812  27 msgs

#7175: unify pydistutils.cfg and distutils.cfg and use .local
http://bugs.python.org/issue7175  27 msgs

#5752: xml.dom.minidom does not escape CR, LF and TAB characters with
http://bugs.python.org/issue5752  26 msgs

#4256: optparse/argparse: provide a simple way to get a programmatica
http://bugs.python.org/issue4256  25 msgs

#1170: shlex have problems with parsing unicode
http://bugs.python.org/issue1170  22 msgs

#3362: locale.getpreferredencoding() gives bus error on Mac OS X 10.4
http://bugs.python.org/issue3362  22 msgs

#2986: difflib.SequenceMatcher not matching long sequences
http://bugs.python.org/issue2986  21 msgs

#7443: test.support.unlink issue on Windows platform
http://bugs.python.org/issue7443  21 msgs



Issues closed (154)
===================

#1474680: pickling files works with protocol=2.
http://bugs.python.org/issue1474680  closed by alexandre.vassalotti

#1540386: SocketServer.ForkingMixIn.collect_children() waits on pid 0
http://bugs.python.org/issue1540386  closed by terry.reedy

#754016: urlparse goes wrong with IP:port without scheme
http://bugs.python.org/issue754016  closed by orsenthil

#1754: WindowsError messages are not properly encoded
http://bugs.python.org/issue1754  closed by terry.reedy

#1978: Python(2.5.1) will be crashed when i use _ssl module in multi-
http://bugs.python.org/issue1978  closed by terry.reedy

#1985: Bug/Patch: Problem with xml/__init__.py when using freeze.py
http://bugs.python.org/issue1985  closed by terry.reedy

#2155: optparse.OptionGroup with_statement context handling
http://bugs.python.org/issue2155  closed by georg.brandl

#2178: Problems with Belarusian Latin locale
http://bugs.python.org/issue2178  closed by terry.reedy

#2204: document ConfigParser behaviour when a file has same section m
http://bugs.python.org/issue2204  closed by merwok

#2423: test_smtplib.py no longer butt slow
http://bugs.python.org/issue2423  closed by richard

#2609: Tests fail if ./@test is not writeable
http://bugs.python.org/issue2609  closed by georg.brandl

#2811: doctest doesn't treat unicode literals as specified by the fil
http://bugs.python.org/issue2811  closed by terry.reedy

#2944: asyncore doesn't handle connection refused correctly
http://bugs.python.org/issue2944  closed by giampaolo.rodola

#3169: email/header.py doesn't handle Base64 headers that have been i
http://bugs.python.org/issue3169  closed by r.david.murray

#3210: subprocess.Popen does not release process handles if process c
http://bugs.python.org/issue3210  closed by tim.golden

#3262: re.split doesn't split with zero-width regex
http://bugs.python.org/issue3262  closed by terry.reedy

#3338: cPickle segfault with deep recursion
http://bugs.python.org/issue3338  closed by terry.reedy

#3467: sqlite3 path is hard coded in setup.py
http://bugs.python.org/issue3467  closed by terry.reedy

#3511: Incorrect charset range handling with ignore case flag?
http://bugs.python.org/issue3511  closed by terry.reedy

#3821: trace module bug when using --missing
http://bugs.python.org/issue3821  closed by georg.brandl

#3854: Document sqlite3 vs. threads
http://bugs.python.org/issue3854  closed by ghaering

#3984: python interpreter import dependency with disutils/util
http://bugs.python.org/issue3984  closed by merwok

#4280: Version Checker
http://bugs.python.org/issue4280  closed by georg.brandl

#4430: time.strptime does not allow same format directive twice
http://bugs.python.org/issue4430  closed by terry.reedy

#4434: Embedding into a shared library fails
http://bugs.python.org/issue4434  closed by terry.reedy

#4491: email.Header.decode_header() doesn't work if encoded-word was 
http://bugs.python.org/issue4491  closed by terry.reedy

#4690: asyncore calls handle_write() on closed sockets when use_poll=
http://bugs.python.org/issue4690  closed by giampaolo.rodola

#4810: timeit needs "official" '--' flag
http://bugs.python.org/issue4810  closed by georg.brandl

#4891: formatwarning function signature change breaks code
http://bugs.python.org/issue4891  closed by georg.brandl

#4943: trace.CoverageResults.write_results can't write results file f
http://bugs.python.org/issue4943  closed by georg.brandl

#4944: os.fsync() doesn't work as expect in Windows
http://bugs.python.org/issue4944  closed by terry.reedy

#4956: Py_Initialize needs to be done before file load (on msys+wine)
http://bugs.python.org/issue4956  closed by terry.reedy

#5077: 2to3 fixer for the removal of operator functions
http://bugs.python.org/issue5077  closed by alexandre.vassalotti

#5320: I/O error during one-liner gives bad diagnostic (and fails to 
http://bugs.python.org/issue5320  closed by georg.brandl

#5414: asciibin.a2b_uu returns unexpected values on non ascii data
http://bugs.python.org/issue5414  closed by terry.reedy

#5551: os.path.ismount takes a cross-device symlink for a mountpoint
http://bugs.python.org/issue5551  closed by georg.brandl

#5671: Speed up pickling of lists in cPickle
http://bugs.python.org/issue5671  closed by alexandre.vassalotti

#5683: Speed up cPickle's pickling generally
http://bugs.python.org/issue5683  closed by alexandre.vassalotti

#5776: RPM build error with python-2.6.spec
http://bugs.python.org/issue5776  closed by georg.brandl

#5898: Hang in Popen.wait() when another process has been created
http://bugs.python.org/issue5898  closed by terry.reedy

#6091: Curses segfaulting in FreeBSD/amd64
http://bugs.python.org/issue6091  closed by terry.reedy

#6140: configure error: shadow.h: present but cannot be compiled
http://bugs.python.org/issue6140  closed by terry.reedy

#6187: Improvement in doc of "Extending and Embedding the Python Inte
http://bugs.python.org/issue6187  closed by georg.brandl

#6251: c++ extension module implementation guide/example in extending
http://bugs.python.org/issue6251  closed by terry.reedy

#6290: cPickle can misread data type
http://bugs.python.org/issue6290  closed by alexandre.vassalotti

#6327: [mimetext] long lines get cut with exclamation mark and newlin
http://bugs.python.org/issue6327  closed by terry.reedy

#6361: I/O object wrappers shouldn't close their underlying file when
http://bugs.python.org/issue6361  closed by alexandre.vassalotti

#6436: trace module doesn't seem to produce .cover files for Py3 (but
http://bugs.python.org/issue6436  closed by georg.brandl

#6439: Demo/embed/demo.c use of PySys_SetArgv() is invalid
http://bugs.python.org/issue6439  closed by georg.brandl

#6443: _winreg.QueryValueEx confused on double null terminated string
http://bugs.python.org/issue6443  closed by terry.reedy

#6520: urllib.urlopen does not have timeout parameter where as urllib
http://bugs.python.org/issue6520  closed by georg.brandl

#6558: #ifdef linux is incorrect; should be #ifdef __linux__ (preferr
http://bugs.python.org/issue6558  closed by terry.reedy

#6580: No deprecation warning for list comprehension leak conflict
http://bugs.python.org/issue6580  closed by terry.reedy

#6636: Non-existant directory in sys.path prevents further imports
http://bugs.python.org/issue6636  closed by terry.reedy

#6728: To avoid hang up in using CGIXMLRPCRequestHandler under IIS 7.
http://bugs.python.org/issue6728  closed by georg.brandl

#6867: return value of epoll.register
http://bugs.python.org/issue6867  closed by georg.brandl

#6928: Doc:  Class statements and metaclass = xxx
http://bugs.python.org/issue6928  closed by georg.brandl

#7280: PCBuild instruction says to use nasmw.exe but it no longer exi
http://bugs.python.org/issue7280  closed by georg.brandl

#7331: Command line testing consistency between 2.x and 3.x
http://bugs.python.org/issue7331  closed by ncoghlan

#7372: Regression in pstats
http://bugs.python.org/issue7372  closed by georg.brandl

#7386: More precise document on os.path.normpath()
http://bugs.python.org/issue7386  closed by georg.brandl

#7395: pstats add command raises unhandled exception
http://bugs.python.org/issue7395  closed by georg.brandl

#7505: ctypes not converting None to Null in 64-bit system
http://bugs.python.org/issue7505  closed by terry.reedy

#7563: yield in except clause causes exception context to be lost
http://bugs.python.org/issue7563  closed by georg.brandl

#7688: TypeError: __name__ must be set to a string object
http://bugs.python.org/issue7688  closed by georg.brandl

#7702: Wrong order of parameters of _get_socket in SMTP class in smtp
http://bugs.python.org/issue7702  closed by georg.brandl

#7781: interactive pstats broken
http://bugs.python.org/issue7781  closed by georg.brandl

#7797: base64 module docs should indicate that encode methods return 
http://bugs.python.org/issue7797  closed by georg.brandl

#7937: windows installer package
http://bugs.python.org/issue7937  closed by georg.brandl

#7942: Inconsistent error types/messages for __len__ (and __nonzero__
http://bugs.python.org/issue7942  closed by terry.reedy

#7952: fileobject.c can switch between fread and fwrite without an in
http://bugs.python.org/issue7952  closed by pitrou

#7973: Wrong spelling of distutils options in error messages and docs
http://bugs.python.org/issue7973  closed by georg.brandl

#8042: mmap buffer implementation does not respect seek pos
http://bugs.python.org/issue8042  closed by pitrou

#8046: mmap.mmap as a context manager
http://bugs.python.org/issue8046  closed by georg.brandl

#8105: mmap crash on Windows with out of range file descriptor
http://bugs.python.org/issue8105  closed by brian.curtin

#8119: Minor comment error in configure.in  ("malloc support" appears
http://bugs.python.org/issue8119  closed by georg.brandl

#8123: TypeError in urllib when trying to use HTTP authentication
http://bugs.python.org/issue8123  closed by orsenthil

#8172: Documentation of Property needs example
http://bugs.python.org/issue8172  closed by georg.brandl

#8196: sqlit3.paramstyle reported as 'qmark'
http://bugs.python.org/issue8196  closed by ghaering

#8230: Lib/test/sortperf.py fails to run
http://bugs.python.org/issue8230  closed by georg.brandl

#8241: py2_test_grammar.py contains invalid syntax for 2.6
http://bugs.python.org/issue8241  closed by loewis

#8249: expat.ParserCreate - SystemError bad argument to internal func
http://bugs.python.org/issue8249  closed by georg.brandl

#8299: Improve GIL in 2.7
http://bugs.python.org/issue8299  closed by terry.reedy

#8397: BZ2File doesn't protect against mixed iterator and read usage
http://bugs.python.org/issue8397  closed by pitrou

#8447: buildbot: test_httpservers failure (No module named operator)
http://bugs.python.org/issue8447  closed by mark.dickinson

#8471: Unicode returns in doctest can make subsequent tests fail
http://bugs.python.org/issue8471  closed by georg.brandl

#8506: SimpleXMLRPCServer Socket not closed after shutdown call
http://bugs.python.org/issue8506  closed by terry.reedy

#8509: fix autoconf quoting in help strings and code snippets
http://bugs.python.org/issue8509  closed by georg.brandl

#8562: hasattr(open,'newlines') example gives incorrect results from 
http://bugs.python.org/issue8562  closed by georg.brandl

#8572: httplib getheader() throws error instead of default
http://bugs.python.org/issue8572  closed by orsenthil

#8612: multiprocessing Queue module failes to send INIConfig objects
http://bugs.python.org/issue8612  closed by georg.brandl

#8620: wrong truncation of last line in cmd.Cmd
http://bugs.python.org/issue8620  closed by r.david.murray

#8648: The UTF-7 codec functions are undocumented
http://bugs.python.org/issue8648  closed by georg.brandl

#8687: sched.py module doesn't have a test suite
http://bugs.python.org/issue8687  closed by giampaolo.rodola

#8735: optparse: parse_args(values=...) does not set up default value
http://bugs.python.org/issue8735  closed by georg.brandl

#8757: Automatic set-to-frozenset conversions not thread-safe
http://bugs.python.org/issue8757  closed by rhettinger

#8758: BUILD_LIST followed by BINARY_SUBSCR can be optimized to a BUI
http://bugs.python.org/issue8758  closed by georg.brandl

#8768: The checkempty_symmetric_difference test is never called
http://bugs.python.org/issue8768  closed by georg.brandl

#8773: mailbox module is needlessly executable
http://bugs.python.org/issue8773  closed by georg.brandl

#8814: functools.WRAPPER_ASSIGNMENTS should include __annotations__
http://bugs.python.org/issue8814  closed by pitrou

#8826: Invalid expires date in cookiejar
http://bugs.python.org/issue8826  closed by georg.brandl

#8861: curses.wrapper : unnessesary code
http://bugs.python.org/issue8861  closed by georg.brandl

#8867: serve.py (using wsgiref) cannot serve Python docs under Python
http://bugs.python.org/issue8867  closed by pitrou

#8873: Popen uses 333 times as much CPU as a shell pipe on Mac OS X
http://bugs.python.org/issue8873  closed by terry.reedy

#9019: wsgiref.headers.Header() does not update headers list it was c
http://bugs.python.org/issue9019  closed by georg.brandl

#9037: Add explanation as to how to raise a custom exception in the e
http://bugs.python.org/issue9037  closed by georg.brandl

#9087: json docstrings on 3.x still use 'unicode' and 'str'
http://bugs.python.org/issue9087  closed by georg.brandl

#9111: cmd.do_help documentation should mention docstrings
http://bugs.python.org/issue9111  closed by georg.brandl

#9190: Undefined behaviour in _PyFloat_Pack4
http://bugs.python.org/issue9190  closed by mark.dickinson

#9209: pstats module crashes on trailing backslash
http://bugs.python.org/issue9209  closed by georg.brandl

#9238: zipfile incorrectly documented as not supporting archive comme
http://bugs.python.org/issue9238  closed by georg.brandl

#9337: Make float.__str__ behave identically to float.__repr__
http://bugs.python.org/issue9337  closed by mark.dickinson

#9413: asyncore.close_all() should call x.handle_close() instead of x
http://bugs.python.org/issue9413  closed by giampaolo.rodola

#9415: SSL issues on "Ubuntu i386" buildbots
http://bugs.python.org/issue9415  closed by pitrou

#9416: complex formatting incorrectly omits a negative zero real part
http://bugs.python.org/issue9416  closed by mark.dickinson

#9428: profile.py bug with the main file being profiled
http://bugs.python.org/issue9428  closed by georg.brandl

#9438: Clarify __debug__ restrictions
http://bugs.python.org/issue9438  closed by georg.brandl

#9444: argparse does not honor prefix_chars when adding default optio
http://bugs.python.org/issue9444  closed by r.david.murray

#9445: Fix undefined symbol errors on VS8.0 build
http://bugs.python.org/issue9445  closed by rhettinger

#9447: Python 3.1.2 test suite segfaults on the alpha architecture
http://bugs.python.org/issue9447  closed by klausman

#9448: test_io leaks memory
http://bugs.python.org/issue9448  closed by pitrou

#9449: glibc detected *** /usr/bin/python: corrupted double-linked li
http://bugs.python.org/issue9449  closed by Nikratio

#9450: readline.replace_history_item leaks memory.
http://bugs.python.org/issue9450  closed by mark.dickinson

#9451: Strengthen __*__ system name warning
http://bugs.python.org/issue9451  closed by georg.brandl

#9454: unittest.expectedFailure decorator does not maintain target fu
http://bugs.python.org/issue9454  closed by mark.smith

#9455: platform test borked in 2.7 branch on Power PC
http://bugs.python.org/issue9455  closed by ronaldoussoren

#9457: Wrong URL in Python-3.2a1/README
http://bugs.python.org/issue9457  closed by georg.brandl

#9496: Unittests for Lib/rlcompleter.py
http://bugs.python.org/issue9496  closed by pitrou

#9497: test_ssl memory leak
http://bugs.python.org/issue9497  closed by mark.dickinson

#9498: stdtypes.rst should refer to sys.float_info
http://bugs.python.org/issue9498  closed by mark.dickinson

#9502: Bus error on OS X while unittest'ing QT app
http://bugs.python.org/issue9502  closed by r.david.murray

#9505: User code should not be able to rebind gc.garbage
http://bugs.python.org/issue9505  closed by pitrou

#9510: sqlite3.Warning isnt a subclass of exceptions.Warning
http://bugs.python.org/issue9510  closed by ghaering

#9513: test_multiprocessing skipped on Windows
http://bugs.python.org/issue9513  closed by brian.curtin

#9515: vars() dictionary access to generate variables
http://bugs.python.org/issue9515  closed by r.david.murray

#9519: IDLE cannot do example 4.1 in tutorial (if statements)
http://bugs.python.org/issue9519  closed by r.david.murray

#9525: webbrowser: open new tab in unobtrusive way
http://bugs.python.org/issue9525  closed by r.david.murray

#9526: 2 GB limit in array module
http://bugs.python.org/issue9526  closed by mark.dickinson

#9531: test_complex.py fails
http://bugs.python.org/issue9531  closed by eli.bendersky

#9534: OrderedDict.__del__ destructor throws AttributeError when proc
http://bugs.python.org/issue9534  closed by rhettinger

#1759845: subprocess.call fails with unicode strings in command line
http://bugs.python.org/issue1759845  closed by terry.reedy

#1443866: email 3.0+ stops parsing headers prematurely
http://bugs.python.org/issue1443866  closed by r.david.murray

#1293741: doctest runner cannot handle non-ascii characters
http://bugs.python.org/issue1293741  closed by terry.reedy

#803422: sgmllib doesn't support hex or Unicode character references
http://bugs.python.org/issue803422  closed by fdrake

#1690103: trace module borks __file__
http://bugs.python.org/issue1690103  closed by georg.brandl

#1635217: Add example of distutils setup() with "requires" argument
http://bugs.python.org/issue1635217  closed by merwok

#1758146: Crash in PyObject_Malloc
http://bugs.python.org/issue1758146  closed by terry.reedy

#1004696: translate Windows newlines when installing scripts on POSIX
http://bugs.python.org/issue1004696  closed by merwok

#1544339: _ctypes fails to build on Solaris x86 32-bit (Sun compiler)
http://bugs.python.org/issue1544339  closed by terry.reedy

#1566260: Better order in file type descriptions
http://bugs.python.org/issue1566260  closed by tim.golden

#818201: distutils: clean does not use build_base option from build
http://bugs.python.org/issue818201  closed by merwok

#1772916: xmlrpclib crash when PyXML installed - sgmlop is available
http://bugs.python.org/issue1772916  closed by georg.brandl

#1540529: cgi.py error on parsing/handling content-disposition
http://bugs.python.org/issue1540529  closed by terry.reedy

#1436203: getpass.getpass() should allow Unicode prompts
http://bugs.python.org/issue1436203  closed by merwok

From linux at gabriel-striewe.de  Tue Aug 10 16:06:20 2010
From: linux at gabriel-striewe.de (linux at gabriel-striewe.de)
Date: Tue, 10 Aug 2010 16:06:20 +0200
Subject: [Python-Dev] mingw support?
In-Reply-To: <i3q110$ncr$1@dough.gmane.org>
References: <20100807195541.GA13990@laptop.gs> <i3n225$osp$1@dough.gmane.org>
	<AANLkTi=dc=0brYo34=xaU6D9wH97eB_tTN=b=FBNjLNh@mail.gmail.com>
	<9f2ea5ad00140f45fdf639eb0b234aea.squirrel@webmail.uio.no>
	<i3q110$ncr$1@dough.gmane.org>
Message-ID: <20100810140620.GB4464@laptop.gs>

On Mon, Aug 09, 2010 at 06:55:29PM -0400, Terry Reedy wrote:
> On 8/9/2010 2:47 PM, Sturla Molden wrote:
> >> Terry Reedy:
> >
> >>     MingW has become less attractive in recent years by the difficulty
> >> in downloading and installing a current version and finding out how to
> >> do so. Some projects have moved on to the TDM packaging of MingW.
> >>
> >> http://tdm-gcc.tdragon.net/
> 
> Someone else deserves credit for writing that and giving that link ;-)

Yes, that was a great link, thanks. It works fine for me.

The reason I was bringing up this topic again was that I think the gnu
autotools have been made for exactly this purpose, to port software to
different platforms, and it might in the long run be easier to have a
working mingw plus autotools platform to develop python (as well as
other software) on.

Besides, one day it would be nice even on windows to have a kind of
GNU/Windows system where you could just type win-emerge gtk or
win-emerge python or whatever. 

Gabriel 

From ezio.melotti at gmail.com  Tue Aug 10 16:28:18 2010
From: ezio.melotti at gmail.com (Ezio Melotti)
Date: Tue, 10 Aug 2010 17:28:18 +0300
Subject: [Python-Dev] Summary of Python tracker Issues
In-Reply-To: <20100810133915.B735578173@psf.upfronthosting.co.za>
References: <20100810133915.B735578173@psf.upfronthosting.co.za>
Message-ID: <4C616202.8010006@gmail.com>

  Hi,
lately I've been working on the new summary of Python tracker issues. 
This is the result.


On 10/08/2010 16.39, Python tracker wrote:
> ACTIVITY SUMMARY (2010-08-01 - 2010-08-07)

This is the period that is considered for the following stats.
By default it shows the activity of the last week.
(This was supposed to be the report for last week, but it's from Monday 
to Sunday instead of from Saturday to Friday because I specified the 
wrong dates.)

> Python tracker at http://bugs.python.org/
>
> To view or respond to any of the issues listed below, click on the issue.
> Do NOT respond to this message.
>
> Issues stats:
>    open    2640 (+35)
>    closed 18679 (+194)
>    total  21319 (+57)

The +35 means that there are 35 more issues opened since the last week. 
This is not the number of issues that have been created during the last 
week, but the number of new issues that have been created or reopened 
that are still open. Also note that 'pending' and 'languishing' are 
considered as 'open' too.
The +194 means that are 194 more issues closed since last week that are 
still closed.
Both the open and closed issues are listed later.
The +57 means that overall the tracker has 57 more issues since last 
week. This also mean that about 25 issues created this week are already 
closed (i.e. 57 new - (35 still open - 3 older that got reopened) = 25 
issues).

> Open issues with patches: 1112
>

This is the total number of open issues with the 'patch' keyword.

> Issues opened (35)
> ==================
>
> #8821: Range check on unicode repr
> http://bugs.python.org/issue8821  reopened by pitrou
> [...]

This is the list of *all* the issues created or reopened during the last 
week *that are still open*.

> Recent issues with no replies (15)
> ==================================
>
> #9535: Pending signals are inherited by child processes
> http://bugs.python.org/issue9535
> [...]

This is the list of the open issues with only 1 message, sorted by 
creation date.
The list is limited to max 15 issues but is not limited to the last 
week. This means that issues older than a week are included here if less 
than 15 issues with only 1 message have been created this week.

> Issues waiting for review (15)
> ==============================
>
> #1474680: pickling files works with protocol=2.
> http://bugs.python.org/issue1474680
> [...]

This is the list of issues with 'patch' or 'needs review' keywords or 
'patch review' stage that have been active during the last week.
The list is limited to max 15 issues.

> Top issues most discussed (10)
> ==============================
>
> #9079: Make gettimeofday available in time module
> http://bugs.python.org/issue9079  42 msgs
> [...]

This is the list of issues with activity in the last week sorted by 
number of message.
This list is limited to max 10 issues.

> Issues closed (154)
> ===================
>
> #1474680: pickling files works with protocol=2.
> http://bugs.python.org/issue1474680  closed by alexandre.vassalotti
> [...]

This is the list of *all* the issues closed in the last week *that are 
still closed*.
Since this list might be quite long I put it at the end, to make it 
easier to reach the other lists.


The previous report also had the average and median durations of open 
issues.
While I was refactoring the function that calculated them, I realized 
that these values are not so useful/clear so I decided to remove them. 
These values could be added back if they are needed, but it might be 
more interesting to know how long does it usually take for an issue to 
be closed, rather than for how long the open issues are around.

For more information see 
http://psf.upfronthosting.co.za/roundup/meta/issue284.

Best Regards,
Ezio Melotti

P.S.: Thanks to R. David Murray that helped me out with the testing and 
to all the people who provided (and will provide) feedback.

From rdmurray at bitdance.com  Tue Aug 10 17:02:48 2010
From: rdmurray at bitdance.com (R. David Murray)
Date: Tue, 10 Aug 2010 11:02:48 -0400
Subject: [Python-Dev] Summary of Python tracker Issues
In-Reply-To: <4C616202.8010006@gmail.com>
References: <20100810133915.B735578173@psf.upfronthosting.co.za>
	<4C616202.8010006@gmail.com>
Message-ID: <20100810150248.D04FD21E509@kimball.webabinitio.net>

On Tue, 10 Aug 2010 17:28:18 +0300, Ezio Melotti <ezio.melotti at gmail.com> wrote:
>   Hi,
> lately I've been working on the new summary of Python tracker issues. 
> This is the result.

Thanks for working on this, Ezio!

> > Issues stats:
> >    open    2640 (+35)
> >    closed 18679 (+194)
> >    total  21319 (+57)
> 
> The +35 means that there are 35 more issues opened since the last week. 
> This is not the number of issues that have been created during the last 
> week, but the number of new issues that have been created or reopened 
> that are still open. Also note that 'pending' and 'languishing' are 
> considered as 'open' too.

How about changing the label to 'not closed' to make that clear?

> > Issues opened (35)
> > ==================
> >
> > #8821: Range check on unicode repr
> > http://bugs.python.org/issue8821  reopened by pitrou
> > [...]
> 
> This is the list of *all* the issues created or reopened during the last 
> week *that are still open*.

I wonder if it would be useful to split this into two tables, one for
new issues still open and one for reopened issues.  I think the mental
space in which one considers re-opened issues is different from the
one for new issues.  In particular, a developer who doesn't have time
to scan the new issues might notice a reopened issue they were involved
in but haven't yet looked at their 'nosy' email about.  Perhaps not
worth the effort, it's just a thought.

> > Recent issues with no replies (15)
> > ==================================
> >
> > #9535: Pending signals are inherited by child processes
> > http://bugs.python.org/issue9535
> > [...]
> 
> This is the list of the open issues with only 1 message, sorted by 
> creation date.
> The list is limited to max 15 issues but is not limited to the last 
> week. This means that issues older than a week are included here if less 
> than 15 issues with only 1 message have been created this week.
> 
> > Issues waiting for review (15)
> > ==============================
> >
> > #1474680: pickling files works with protocol=2.
> > http://bugs.python.org/issue1474680
> > [...]
> 
> This is the list of issues with 'patch' or 'needs review' keywords or 
> 'patch review' stage that have been active during the last week.
> The list is limited to max 15 issues.

For both of these I think it is important that the fact that they
are limited to 15 be mentioned in the section header.

The issues needing review is a great addition, probably every bit
as valuable as the no replies report.  I hope that it, too, will
draw on the previous weeks if there are less than fifteen that
were active in the current week?

> > Top issues most discussed (10)
> > ==============================
> >
> > #9079: Make gettimeofday available in time module
> > http://bugs.python.org/issue9079  42 msgs
> > [...]
> 
> This is the list of issues with activity in the last week sorted by 
> number of message.
> This list is limited to max 10 issues.

I've already talked with Ezio in IRC about the fact that this list
represents a regression from the old report, since the old report
gave the issues with the most messages *during the week* whereas
his current looks at the *total* message count for any issue that
has had *any* activity during the current week.  He's going to fix
that.

> > Issues closed (154)
> > ===================
> >
> > #1474680: pickling files works with protocol=2.
> > http://bugs.python.org/issue1474680  closed by alexandre.vassalotti
> > [...]
> 
> This is the list of *all* the issues closed in the last week *that are 
> still closed*.
> Since this list might be quite long I put it at the end, to make it 
> easier to reach the other lists.

It would be lovely if we could manage to get this one to be the
longest table in the report each week :)

--
R. David Murray                                      www.bitdance.com

From alexander.belopolsky at gmail.com  Tue Aug 10 17:47:15 2010
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Tue, 10 Aug 2010 11:47:15 -0400
Subject: [Python-Dev] [Python-checkins] r83893 -
	python/branches/release27-maint/Misc/ACKS
In-Reply-To: <4C60E96F.2090402@v.loewis.de>
References: <20100809161007.81567EE9F7@mail.python.org>
	<AANLkTimWa_M_Zzt+QJEkTvr7ijY9yCYsR6afVUci1z1x@mail.gmail.com>
	<AANLkTin5yFjNMCBYxV2+dMsNdB95bt_z3zOiVdG=jQJr@mail.gmail.com>
	<14CCDAF6-743E-4A95-9D44-9A119855F476@gmail.com>
	<AANLkTi=64xPHwKCYi0AHa5rT9R4XcTn7wobWvS=0qeuK@mail.gmail.com>
	<AANLkTinMUkwe_RWU7WonrGp2OdM_TrXb4ZRyt+hcfxnc@mail.gmail.com>
	<4C60E96F.2090402@v.loewis.de>
Message-ID: <AANLkTinBtwEP3nPkU8WLm5ocWkFeiU4tyDbcWhht+_S6@mail.gmail.com>

On Tue, Aug 10, 2010 at 1:53 AM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
..
> People need to recognize that any kind of reference is really irrelevant
> here. There is no "right" order that is better than any other "right"
> order. I'd personally object to any English language dictionary telling
> me how my name sorts in the alphabet.
>
Even when an English language dictionary follows German rules?  :-)
BTW,  I did quietly bring Peter ?strand back to the end of the list
yesterday and I agree that this is rather unimportant.

> (and yes, I do think it's "wrong" that it got sorted after Lyngvig -
> in Germany, we put the ? as if it was "oe" - unlike the Swedes, which
> put the very same letter after the rest of the alphabet. So the
> ? in Chrigstr?m sorts in a different way than the ? in L?wis. If I move
> to Sweden, the file would have to change :-)

I did search the mail archives for the discussion of ?'s sorting order
and now I think that the reference to Swedish rules is an ex-post
rationalization.  It looks like the original order was by Latin-1 code
point and that explains both ? and ? positions.  (I actually believe
that the Swedish rules are fairly modern as well.  Unlike other
nations,  Swedes don't mind breaking with traditions for modern
conveniences.  As far as I know, Sweden is the only nation where
polite "you" (plural) was abolished by a language reform.)

I raised this issue after one of my early check-ins got a response
that acknowledgments should be alphabetized rather than added at the
end of the list. [1]   I pointed out that given that the file is
encoded in UTF-8, it can potentially have last names starting with any
unicode character and I was not familiar with any formal procedure
that would define an alphabetic order in this case.   A short
brainstorming session on IRC and the tracker resulted with an
agreement that no formal rule exists and the best we can do is to
define the order as "rough".

I am not 100% happy with this because I am sure people will keep
discovering that the order in the file does not match the order
suggested by their favorite sort program.   I was also hoping to learn
from this discussion what the state of the art in in sorting unicode
words is.  I believe this issue is addressed by some obscure parts of
the unicode standard, but I am not familiar with them.


[1] http://mail.python.org/pipermail/python-checkins/2010-May/093650.html

From cournape at gmail.com  Tue Aug 10 18:23:31 2010
From: cournape at gmail.com (David Cournapeau)
Date: Wed, 11 Aug 2010 01:23:31 +0900
Subject: [Python-Dev] mingw support?
In-Reply-To: <20100810140620.GB4464@laptop.gs>
References: <20100807195541.GA13990@laptop.gs> <i3n225$osp$1@dough.gmane.org>
	<AANLkTi=dc=0brYo34=xaU6D9wH97eB_tTN=b=FBNjLNh@mail.gmail.com>
	<9f2ea5ad00140f45fdf639eb0b234aea.squirrel@webmail.uio.no>
	<i3q110$ncr$1@dough.gmane.org> <20100810140620.GB4464@laptop.gs>
Message-ID: <AANLkTik0QoHNXGgqhbtQKJqrFoC3kxzzomm06sJfZLJ8@mail.gmail.com>

On Tue, Aug 10, 2010 at 11:06 PM,  <linux at gabriel-striewe.de> wrote:
> On Mon, Aug 09, 2010 at 06:55:29PM -0400, Terry Reedy wrote:
>> On 8/9/2010 2:47 PM, Sturla Molden wrote:
>> >> Terry Reedy:
>> >
>> >> ? ? MingW has become less attractive in recent years by the difficulty
>> >> in downloading and installing a current version and finding out how to
>> >> do so. Some projects have moved on to the TDM packaging of MingW.
>> >>
>> >> http://tdm-gcc.tdragon.net/
>>
>> Someone else deserves credit for writing that and giving that link ;-)
>
> Yes, that was a great link, thanks. It works fine for me.
>
> The reason I was bringing up this topic again was that I think the gnu
> autotools have been made for exactly this purpose, to port software to
> different platforms,

Autotools only help for posix-like platforms. They are certainly a big
hindrance on windows platform in general,

cheers,

David

From tjreedy at udel.edu  Tue Aug 10 20:53:40 2010
From: tjreedy at udel.edu (Terry Reedy)
Date: Tue, 10 Aug 2010 14:53:40 -0400
Subject: [Python-Dev] Summary of Python tracker Issues
In-Reply-To: <4C616202.8010006@gmail.com>
References: <20100810133915.B735578173@psf.upfronthosting.co.za>
	<4C616202.8010006@gmail.com>
Message-ID: <i3s77j$4r6$1@dough.gmane.org>

On 8/10/2010 10:28 AM, Ezio Melotti wrote:

> This is the list of *all* the issues created or reopened during the last
> week *that are still open*.

Thank you for removing the duplication of listing issues opened and 
closed twice. I otherwise pretty much agree with RDM's comments.

-- 
Terry Jan Reedy


From tjreedy at udel.edu  Tue Aug 10 21:25:52 2010
From: tjreedy at udel.edu (Terry Reedy)
Date: Tue, 10 Aug 2010 15:25:52 -0400
Subject: [Python-Dev] r83893 - python/branches/release27-maint/Misc/ACKS
In-Reply-To: <AANLkTimeKq6H9qh3=c1PpbgC8k0H12sFHze3DBE-72qu@mail.gmail.com>
References: <20100809161007.81567EE9F7@mail.python.org>	<AANLkTimWa_M_Zzt+QJEkTvr7ijY9yCYsR6afVUci1z1x@mail.gmail.com>	<AANLkTin5yFjNMCBYxV2+dMsNdB95bt_z3zOiVdG=jQJr@mail.gmail.com>	<874of2ew2x.fsf@uwakimon.sk.tsukuba.ac.jp>
	<AANLkTimeKq6H9qh3=c1PpbgC8k0H12sFHze3DBE-72qu@mail.gmail.com>
Message-ID: <i3s940$ino$1@dough.gmane.org>

On 8/10/2010 9:13 AM, Benjamin Peterson wrote:
> 2010/8/10 Stephen J. Turnbull<stephen at xemacs.org>:
>> Benjamin Peterson writes:
>>   >  2010/8/9 Nick Coghlan<ncoghlan at gmail.com>:
>>   >  >  On Tue, Aug 10, 2010 at 2:10 AM, alexander.belopolsky
>>   >  >  <python-checkins at python.org>  wrote:
>>   >  >>  +PS: In the standard Python distribution, this file is encoded
>>   >  >>  in UTF-8 +and the list is in rough alphabetical order by last
>>   >  >>  names.
>>   >  >>
>>   >  >>    David Abrahams
>>   >  >>    Jim Ahlstrom
>>   >  >>  @@ -28,6 +29,7 @@
>>   >  >>    ?ric Araujo
>>   >  >>    Jason Asbahr
>>   >  >>    David Ascher
>>   >  >>  +Peter ?strand
>>   >  >   From my recollection of the discussion when Peter was added, the
>>   >  >  >first
>>   >  >  character in his last name actually sorts after Z (despite its
>>   >  >  resemblance to an A).
>>   >  This is correct. Don't think of ? as a kind of "A". It's its own
>>   >  letter, which sorts after Z in Swedish.
>>
>> That's true, but IIRC there are a fairly large number of letters where
>> different languages collate them in different positions.
>>
>> Is it worth actually asking appropriate humans to think about this, or
>> would it be better to use Unicode code point order for simplicity?
>
> I think it's largely a unimportant discussion. If people have an
> opinion of where their name should appear, they can by all means
> change it. However, "rough" is probably as best as it'll ever get.

If I were committing a patch and was checking to see whether a name that 
started with a decorated A (or any other letter) were already in the 
list, I would look in the appropriate place in the A (or other) section, 
not after Z.

Everyone working on the English-based Python distribution knows the 
order of the 26 English letters. Please use that order (including for 
decorated versions and tranliterations) instead of various idiosyncratic 
and possibly conflicting nationality-based rules.

For instance, suppose a 'Jean Charbol' posts a patch? Should we really 
have to ask his/her 'nationality' before adding the name to the list? 
Suppose 'Charbol' was born in Spain but works in France? In Spain, at 
least, 'ch' words are alphabetized in dictionaries between 'c' and 'd' 
words. Did everyone already know that? I an mot ever sure if all 
Spanish-speaking countries still do that.

I am under the impression that either the Irish or Scots have some fussy 
rules for Mc/Mac/O names but I don't know them and don't think we should 
observe them in our list.

Librarians who filed author cards by birth nationality rules made the 
now-obsolete card catalogs less useful for users who not know both birth 
nationality and rule. Lets not repeat that mistake.

-- 
Terry Jan Reedy



From tjreedy at udel.edu  Tue Aug 10 21:38:33 2010
From: tjreedy at udel.edu (Terry Reedy)
Date: Tue, 10 Aug 2010 15:38:33 -0400
Subject: [Python-Dev] r83893 - python/branches/release27-maint/Misc/ACKS
In-Reply-To: <i3s940$ino$1@dough.gmane.org>
References: <20100809161007.81567EE9F7@mail.python.org>	<AANLkTimWa_M_Zzt+QJEkTvr7ijY9yCYsR6afVUci1z1x@mail.gmail.com>	<AANLkTin5yFjNMCBYxV2+dMsNdB95bt_z3zOiVdG=jQJr@mail.gmail.com>	<874of2ew2x.fsf@uwakimon.sk.tsukuba.ac.jp>	<AANLkTimeKq6H9qh3=c1PpbgC8k0H12sFHze3DBE-72qu@mail.gmail.com>
	<i3s940$ino$1@dough.gmane.org>
Message-ID: <i3s9ro$non$1@dough.gmane.org>

On 8/10/2010 3:25 PM, Terry Reedy wrote:

> Everyone working on the English-based Python distribution knows the
> order of the 26 English letters. Please use that order (including for
> decorated versions and tranliterations) instead of various idiosyncratic
> and possibly conflicting nationality-based rules.

Since the list is now utf-8 instead of latin-1 encoded, we could include 
the actual native character name, if supplied, in parentheses after the 
English-alphabetized transliteration.

If we were to follow native rules, all Japanese names, for instance, 
should be separately listed and ordered according to the Japanese order, 
which is quite different from the European orders.

-- 
Terry Jan Reedy


From benjamin at python.org  Tue Aug 10 21:44:50 2010
From: benjamin at python.org (Benjamin Peterson)
Date: Tue, 10 Aug 2010 14:44:50 -0500
Subject: [Python-Dev] r83893 - python/branches/release27-maint/Misc/ACKS
In-Reply-To: <i3s940$ino$1@dough.gmane.org>
References: <20100809161007.81567EE9F7@mail.python.org>
	<AANLkTimWa_M_Zzt+QJEkTvr7ijY9yCYsR6afVUci1z1x@mail.gmail.com>
	<AANLkTin5yFjNMCBYxV2+dMsNdB95bt_z3zOiVdG=jQJr@mail.gmail.com>
	<874of2ew2x.fsf@uwakimon.sk.tsukuba.ac.jp>
	<AANLkTimeKq6H9qh3=c1PpbgC8k0H12sFHze3DBE-72qu@mail.gmail.com>
	<i3s940$ino$1@dough.gmane.org>
Message-ID: <AANLkTimTvAFztyo9HbDUD2ba8qCsrU14oNkY5Qx4747M@mail.gmail.com>

2010/8/10 Terry Reedy <tjreedy at udel.edu>:
> On 8/10/2010 9:13 AM, Benjamin Peterson wrote:
>>
>> 2010/8/10 Stephen J. Turnbull<stephen at xemacs.org>:
>>>
>>> Benjamin Peterson writes:
>>> ?> ?2010/8/9 Nick Coghlan<ncoghlan at gmail.com>:
>>> ?> ?> ?On Tue, Aug 10, 2010 at 2:10 AM, alexander.belopolsky
>>> ?> ?> ?<python-checkins at python.org> ?wrote:
>>> ?> ?>> ?+PS: In the standard Python distribution, this file is encoded
>>> ?> ?>> ?in UTF-8 +and the list is in rough alphabetical order by last
>>> ?> ?>> ?names.
>>> ?> ?>>
>>> ?> ?>> ? ?David Abrahams
>>> ?> ?>> ? ?Jim Ahlstrom
>>> ?> ?>> ?@@ -28,6 +29,7 @@
>>> ?> ?>> ? ??ric Araujo
>>> ?> ?>> ? ?Jason Asbahr
>>> ?> ?>> ? ?David Ascher
>>> ?> ?>> ?+Peter ?strand
>>> ?> ?> ? From my recollection of the discussion when Peter was added, the
>>> ?> ?> ?>first
>>> ?> ?> ?character in his last name actually sorts after Z (despite its
>>> ?> ?> ?resemblance to an A).
>>> ?> ?This is correct. Don't think of ? as a kind of "A". It's its own
>>> ?> ?letter, which sorts after Z in Swedish.
>>>
>>> That's true, but IIRC there are a fairly large number of letters where
>>> different languages collate them in different positions.
>>>
>>> Is it worth actually asking appropriate humans to think about this, or
>>> would it be better to use Unicode code point order for simplicity?
>>
>> I think it's largely a unimportant discussion. If people have an
>> opinion of where their name should appear, they can by all means
>> change it. However, "rough" is probably as best as it'll ever get.
>
> If I were committing a patch and was checking to see whether a name that
> started with a decorated A (or any other letter) were already in the list, I
> would look in the appropriate place in the A (or other) section, not after
> Z.
>
> Everyone working on the English-based Python distribution knows the order of
> the 26 English letters. Please use that order (including for decorated
> versions and tranliterations) instead of various idiosyncratic and possibly
> conflicting nationality-based rules.
>
> For instance, suppose a 'Jean Charbol' posts a patch? Should we really have
> to ask his/her 'nationality' before adding the name to the list?

No, but if he complains about it, we should change it.

> Librarians who filed author cards by birth nationality rules made the
> now-obsolete card catalogs less useful for users who not know both birth
> nationality and rule. Lets not repeat that mistake.

How often are people trying to search through Misc/ACKS, though?



-- 
Regards,
Benjamin

From alexander.belopolsky at gmail.com  Tue Aug 10 22:08:52 2010
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Tue, 10 Aug 2010 16:08:52 -0400
Subject: [Python-Dev] r83893 - python/branches/release27-maint/Misc/ACKS
In-Reply-To: <i3s940$ino$1@dough.gmane.org>
References: <20100809161007.81567EE9F7@mail.python.org>
	<AANLkTimWa_M_Zzt+QJEkTvr7ijY9yCYsR6afVUci1z1x@mail.gmail.com>
	<AANLkTin5yFjNMCBYxV2+dMsNdB95bt_z3zOiVdG=jQJr@mail.gmail.com>
	<874of2ew2x.fsf@uwakimon.sk.tsukuba.ac.jp>
	<AANLkTimeKq6H9qh3=c1PpbgC8k0H12sFHze3DBE-72qu@mail.gmail.com>
	<i3s940$ino$1@dough.gmane.org>
Message-ID: <AANLkTi=sT3OmKPfz3oa5vVxhLcMzW-VQ83=QfrGzQqaN@mail.gmail.com>

On Tue, Aug 10, 2010 at 3:25 PM, Terry Reedy <tjreedy at udel.edu> wrote:
..
> If I were committing a patch and was checking to see whether a name that
> started with a decorated A (or any other letter) were already in the list, I
> would look in the appropriate place in the A (or other) section, not after
> Z.
>
> Everyone working on the English-based Python distribution knows the order of
> the 26 English letters. Please use that order (including for decorated
> versions and tranliterations) instead of various idiosyncratic and possibly
> conflicting nationality-based rules.
>

I believe, the golden standard for this type of works can be found in
the index pages of The Art of Computer Programming,

http://www-cs-faculty.stanford.edu/~knuth/help.html#exotic

It would be quite an effort to redo Misc/ACKS in that way, and even
with ASCII transliteration of every name, there is still ambiguity: is
"Van Rossum" sorted under "V", or under "R"? (See
http://www.python.org/~guido/ for an answer.)

Since it is apparent that no formal rule can be agreed upon, I think
best effort "rough alphabetical" order is just fine.  BTW, what is
Arfrever Frehtes Taifersar Arahesis' last name? :-)

From tjreedy at udel.edu  Tue Aug 10 22:21:01 2010
From: tjreedy at udel.edu (Terry Reedy)
Date: Tue, 10 Aug 2010 16:21:01 -0400
Subject: [Python-Dev] r83893 - python/branches/release27-maint/Misc/ACKS
In-Reply-To: <AANLkTimTvAFztyo9HbDUD2ba8qCsrU14oNkY5Qx4747M@mail.gmail.com>
References: <20100809161007.81567EE9F7@mail.python.org>	<AANLkTimWa_M_Zzt+QJEkTvr7ijY9yCYsR6afVUci1z1x@mail.gmail.com>	<AANLkTin5yFjNMCBYxV2+dMsNdB95bt_z3zOiVdG=jQJr@mail.gmail.com>	<874of2ew2x.fsf@uwakimon.sk.tsukuba.ac.jp>	<AANLkTimeKq6H9qh3=c1PpbgC8k0H12sFHze3DBE-72qu@mail.gmail.com>	<i3s940$ino$1@dough.gmane.org>
	<AANLkTimTvAFztyo9HbDUD2ba8qCsrU14oNkY5Qx4747M@mail.gmail.com>
Message-ID: <i3scbd$86e$1@dough.gmane.org>

On 8/10/2010 3:44 PM, Benjamin Peterson wrote:

> No, but if he complains about it, we should change it.

If "In rough English alphabetical order" is extended with "unless the 
person requests otherwise", then it should also be extended with "in 
which case the name is suffixed with '(phbr)' [or something similar] for 
'put here by request'" so that a later, diligent person seeking to 
improve the ordering will not think that it out of standard order by 
accident or initial committer laziness and move it back. I believe we 
are having this discussion in part precisedly because Astrand after Z 
was not so tagged and was thought to have just been quickly appended.

-- 
Terry Jan Reedy


From martin at v.loewis.de  Wed Aug 11 00:01:50 2010
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 11 Aug 2010 00:01:50 +0200
Subject: [Python-Dev] [Python-checkins] r83893 -
	python/branches/release27-maint/Misc/ACKS
In-Reply-To: <AANLkTinBtwEP3nPkU8WLm5ocWkFeiU4tyDbcWhht+_S6@mail.gmail.com>
References: <20100809161007.81567EE9F7@mail.python.org>	<AANLkTimWa_M_Zzt+QJEkTvr7ijY9yCYsR6afVUci1z1x@mail.gmail.com>	<AANLkTin5yFjNMCBYxV2+dMsNdB95bt_z3zOiVdG=jQJr@mail.gmail.com>	<14CCDAF6-743E-4A95-9D44-9A119855F476@gmail.com>	<AANLkTi=64xPHwKCYi0AHa5rT9R4XcTn7wobWvS=0qeuK@mail.gmail.com>	<AANLkTinMUkwe_RWU7WonrGp2OdM_TrXb4ZRyt+hcfxnc@mail.gmail.com>	<4C60E96F.2090402@v.loewis.de>
	<AANLkTinBtwEP3nPkU8WLm5ocWkFeiU4tyDbcWhht+_S6@mail.gmail.com>
Message-ID: <4C61CC4E.3030900@v.loewis.de>

> I am not 100% happy with this because I am sure people will keep
> discovering that the order in the file does not match the order
> suggested by their favorite sort program.   I was also hoping to learn
> from this discussion what the state of the art in in sorting unicode
> words is.  I believe this issue is addressed by some obscure parts of
> the unicode standard, but I am not familiar with them.

Actually, it's not. Rather, Unicode acknowledges that collation depends
on the locale, see

http://unicode.org/reports/tr10/

Of course, it would be possible to follow the Default Unicode Collation
Element Table (DUCET).

Regards,
Martin

From martin at v.loewis.de  Wed Aug 11 00:29:25 2010
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Wed, 11 Aug 2010 00:29:25 +0200
Subject: [Python-Dev] r83893 - python/branches/release27-maint/Misc/ACKS
In-Reply-To: <i3s940$ino$1@dough.gmane.org>
References: <20100809161007.81567EE9F7@mail.python.org>	<AANLkTimWa_M_Zzt+QJEkTvr7ijY9yCYsR6afVUci1z1x@mail.gmail.com>	<AANLkTin5yFjNMCBYxV2+dMsNdB95bt_z3zOiVdG=jQJr@mail.gmail.com>	<874of2ew2x.fsf@uwakimon.sk.tsukuba.ac.jp>	<AANLkTimeKq6H9qh3=c1PpbgC8k0H12sFHze3DBE-72qu@mail.gmail.com>
	<i3s940$ino$1@dough.gmane.org>
Message-ID: <4C61D2C5.8050806@v.loewis.de>


> If I were committing a patch and was checking to see whether a name that
> started with a decorated A (or any other letter) were already in the
> list, I would look in the appropriate place in the A (or other) section,
> not after Z.
> 
> Everyone working on the English-based Python distribution knows the
> order of the 26 English letters. Please use that order (including for
> decorated versions and tranliterations) instead of various idiosyncratic
> and possibly conflicting nationality-based rules.

So where do you put ???????? ?????????????

Regards,
Martin

From alexander.belopolsky at gmail.com  Wed Aug 11 00:35:11 2010
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Tue, 10 Aug 2010 18:35:11 -0400
Subject: [Python-Dev] r83893 - python/branches/release27-maint/Misc/ACKS
In-Reply-To: <4C61D2C5.8050806@v.loewis.de>
References: <20100809161007.81567EE9F7@mail.python.org>
	<AANLkTimWa_M_Zzt+QJEkTvr7ijY9yCYsR6afVUci1z1x@mail.gmail.com>
	<AANLkTin5yFjNMCBYxV2+dMsNdB95bt_z3zOiVdG=jQJr@mail.gmail.com>
	<874of2ew2x.fsf@uwakimon.sk.tsukuba.ac.jp>
	<AANLkTimeKq6H9qh3=c1PpbgC8k0H12sFHze3DBE-72qu@mail.gmail.com>
	<i3s940$ino$1@dough.gmane.org> <4C61D2C5.8050806@v.loewis.de>
Message-ID: <AANLkTimSEnQe53Cq=K_0uzmnDdOBMrdF_1sDuo4JPPJZ@mail.gmail.com>

On Tue, Aug 10, 2010 at 6:29 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
..
> So where do you put ???????? ?????????????
>

or ????????? ???????????? for that matter? :-)

From ziade.tarek at gmail.com  Wed Aug 11 00:45:13 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 11 Aug 2010 00:45:13 +0200
Subject: [Python-Dev] r83893 - python/branches/release27-maint/Misc/ACKS
In-Reply-To: <AANLkTimSEnQe53Cq=K_0uzmnDdOBMrdF_1sDuo4JPPJZ@mail.gmail.com>
References: <20100809161007.81567EE9F7@mail.python.org>
	<AANLkTimWa_M_Zzt+QJEkTvr7ijY9yCYsR6afVUci1z1x@mail.gmail.com>
	<AANLkTin5yFjNMCBYxV2+dMsNdB95bt_z3zOiVdG=jQJr@mail.gmail.com>
	<874of2ew2x.fsf@uwakimon.sk.tsukuba.ac.jp>
	<AANLkTimeKq6H9qh3=c1PpbgC8k0H12sFHze3DBE-72qu@mail.gmail.com>
	<i3s940$ino$1@dough.gmane.org> <4C61D2C5.8050806@v.loewis.de>
	<AANLkTimSEnQe53Cq=K_0uzmnDdOBMrdF_1sDuo4JPPJZ@mail.gmail.com>
Message-ID: <AANLkTikTwLMsv6dCw5FbPcFjWtrWOTyC-XrUW+Pxs-pk@mail.gmail.com>

On Wed, Aug 11, 2010 at 12:35 AM, Alexander Belopolsky
<alexander.belopolsky at gmail.com> wrote:
> On Tue, Aug 10, 2010 at 6:29 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> ..
>> So where do you put ???????? ?????????????
>>
>
> or ????????? ???????????? for that matter? :-)

James Tauber did a UCA implementation in Python it seems:
http://jtauber.com/blog/2006/01/27/python_unicode_collation_algorithm/,

we could use this as a pre-commit hook to check changes on ACKS ;)

From martin at v.loewis.de  Wed Aug 11 00:50:05 2010
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Wed, 11 Aug 2010 00:50:05 +0200
Subject: [Python-Dev] r83893 - python/branches/release27-maint/Misc/ACKS
In-Reply-To: <AANLkTimSEnQe53Cq=K_0uzmnDdOBMrdF_1sDuo4JPPJZ@mail.gmail.com>
References: <20100809161007.81567EE9F7@mail.python.org>	<AANLkTimWa_M_Zzt+QJEkTvr7ijY9yCYsR6afVUci1z1x@mail.gmail.com>	<AANLkTin5yFjNMCBYxV2+dMsNdB95bt_z3zOiVdG=jQJr@mail.gmail.com>	<874of2ew2x.fsf@uwakimon.sk.tsukuba.ac.jp>	<AANLkTimeKq6H9qh3=c1PpbgC8k0H12sFHze3DBE-72qu@mail.gmail.com>	<i3s940$ino$1@dough.gmane.org>	<4C61D2C5.8050806@v.loewis.de>
	<AANLkTimSEnQe53Cq=K_0uzmnDdOBMrdF_1sDuo4JPPJZ@mail.gmail.com>
Message-ID: <4C61D79D.1080907@v.loewis.de>

Am 11.08.2010 00:35, schrieb Alexander Belopolsky:
> On Tue, Aug 10, 2010 at 6:29 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> ..
>> So where do you put ???????? ?????????????
>>
> 
> or ????????? ???????????? for that matter? :-)

If you care about that, feel free to add that spelling to the file.
Somebody proposed to put it along with some latin transliteration,
which I can sympathize with.

If just the nickname in cyrillic is fine with you, it's of course
fine, as well.

Regards,
Martin

From alexander.belopolsky at gmail.com  Wed Aug 11 00:56:06 2010
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Tue, 10 Aug 2010 18:56:06 -0400
Subject: [Python-Dev] r83893 - python/branches/release27-maint/Misc/ACKS
In-Reply-To: <4C61D79D.1080907@v.loewis.de>
References: <20100809161007.81567EE9F7@mail.python.org>
	<AANLkTimWa_M_Zzt+QJEkTvr7ijY9yCYsR6afVUci1z1x@mail.gmail.com>
	<AANLkTin5yFjNMCBYxV2+dMsNdB95bt_z3zOiVdG=jQJr@mail.gmail.com>
	<874of2ew2x.fsf@uwakimon.sk.tsukuba.ac.jp>
	<AANLkTimeKq6H9qh3=c1PpbgC8k0H12sFHze3DBE-72qu@mail.gmail.com>
	<i3s940$ino$1@dough.gmane.org> <4C61D2C5.8050806@v.loewis.de>
	<AANLkTimSEnQe53Cq=K_0uzmnDdOBMrdF_1sDuo4JPPJZ@mail.gmail.com>
	<4C61D79D.1080907@v.loewis.de>
Message-ID: <AANLkTim5khHr-MUtnf6esD--CSNfM8yKK+EN50s1AGF7@mail.gmail.com>

On Tue, Aug 10, 2010 at 6:50 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
..
>> or ????????? ???????????? for that matter? :-)
>
> If you care about that, feel free to add that spelling to the file.
> Somebody proposed to put it along with some latin transliteration,
> which I can sympathize with.
>
That was Donald Knuth:
http://www-cs-faculty.stanford.edu/~knuth/help.html#exotic

> If just the nickname in cyrillic is fine with you, it's of course
> fine, as well.

I am more than happy with my entry in its current form. :-)

BTW, does anybody know if

Jiba = Jean-Baptiste LAMY ("Jiba")?

CCing SF address to find out.

From ncoghlan at gmail.com  Wed Aug 11 04:30:40 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 11 Aug 2010 12:30:40 +1000
Subject: [Python-Dev] Proposed tweaks to functools.wraps
Message-ID: <AANLkTimQhkeUWHBLrsmW+JDOMimgjnpxihUh1L894Zoz@mail.gmail.com>

Based on a pair of tracker issues (#3445 and #9396) I'm considering a
couple of adjustments to functools.wraps for 3.2.

The first (#3445) is a request from ages ago to make update_wrapper
more forgiving when it encounters a missing attribute. Instead of
throwing AttributeError (as it does now), it would just skip the
missing attribute. This would allow wraps to be used with other
callables that don't fully mimic the function API. I was initially
opposed to the idea, but over time I've come to think this is a case
where practicality beats purity (since that really sums up
functools.wraps in general - it is already the case that the copied
info isn't quite right for the decorated function, but it's still
better than using the wrapper function's own metadata).

The second (#9396) came up in the context of the new cache decorators
added to functools, and allowing applications to choose their own
caching strategies. I suggested exposing the original (uncached)
function, and Raymond suggested that the easiest way to enable that
would be for functools.update_wrapper to add a new attribute that
provides a reference to the original function. Some time back, we
considered doing this automatically as an integral part of decoration,
but decided that wasn't appropriate. However, building it into the
explicit wrapping functions makes sense to me. To avoid namespace
conflicts, I plan to use "__wraps__" as the name for the reference to
the original function.

Thoughts? Concerns? Better ideas?

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From benjamin at python.org  Wed Aug 11 04:39:42 2010
From: benjamin at python.org (Benjamin Peterson)
Date: Tue, 10 Aug 2010 21:39:42 -0500
Subject: [Python-Dev] Proposed tweaks to functools.wraps
In-Reply-To: <AANLkTimQhkeUWHBLrsmW+JDOMimgjnpxihUh1L894Zoz@mail.gmail.com>
References: <AANLkTimQhkeUWHBLrsmW+JDOMimgjnpxihUh1L894Zoz@mail.gmail.com>
Message-ID: <AANLkTikzBmQcdiLP+oDzeCd9jO4bzuN7msjs9=MfmTXb@mail.gmail.com>

2010/8/10 Nick Coghlan <ncoghlan at gmail.com>:
> Based on a pair of tracker issues (#3445 and #9396) I'm considering a
> couple of adjustments to functools.wraps for 3.2.
>
> The first (#3445) is a request from ages ago to make update_wrapper
> more forgiving when it encounters a missing attribute. Instead of
> throwing AttributeError (as it does now), it would just skip the
> missing attribute. This would allow wraps to be used with other
> callables that don't fully mimic the function API. I was initially
> opposed to the idea, but over time I've come to think this is a case
> where practicality beats purity (since that really sums up
> functools.wraps in general - it is already the case that the copied
> info isn't quite right for the decorated function, but it's still
> better than using the wrapper function's own metadata).

That seems fine. With class decorators, I suppose it might be possible
to have something like:

def class_deco(cls):
    @functools.wraps(cls)
    class Spam:
         pass
@class_deco
class Eggs: pass

which would require ignoring the absence of __annotations__.

>
> The second (#9396) came up in the context of the new cache decorators
> added to functools, and allowing applications to choose their own
> caching strategies. I suggested exposing the original (uncached)
> function, and Raymond suggested that the easiest way to enable that
> would be for functools.update_wrapper to add a new attribute that
> provides a reference to the original function. Some time back, we
> considered doing this automatically as an integral part of decoration,
> but decided that wasn't appropriate. However, building it into the
> explicit wrapping functions makes sense to me. To avoid namespace
> conflicts, I plan to use "__wraps__" as the name for the reference to
> the original function.

Namespace conflict with what? I would prefer "wraps" unless it's
standardized as a behavior for all decorators.



-- 
Regards,
Benjamin

From merwok at netwok.org  Wed Aug 11 04:48:03 2010
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Wed, 11 Aug 2010 04:48:03 +0200
Subject: [Python-Dev] Proposed tweaks to functools.wraps
In-Reply-To: <AANLkTimQhkeUWHBLrsmW+JDOMimgjnpxihUh1L894Zoz@mail.gmail.com>
References: <AANLkTimQhkeUWHBLrsmW+JDOMimgjnpxihUh1L894Zoz@mail.gmail.com>
Message-ID: <4C620F63.6050807@netwok.org>

> The second (#9396) came up in the context of the new cache decorators
> added to functools, and allowing applications to choose their own
> caching strategies. I suggested exposing the original (uncached)
> function, and Raymond suggested that the easiest way to enable that
> would be for functools.update_wrapper to add a new attribute that
> provides a reference to the original function.

I moved this feature request to its own bug after brief IRC discussion
with RDM: http://bugs.python.org/issue9567

The idea was to separate concerns and eventually get feedback from
people reading new-bugs-announce, but your email actually does that :)

I say ?add attribute to partial objects? in the bug title since I don?t
know if it?s feasible in wraps only; while update_wrapper is simple
Python code, wraps merely delegates to _functools.partial, so please
change the title (and maybe add easy keyword) if appropriate.

Regards


From ncoghlan at gmail.com  Wed Aug 11 04:58:54 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 11 Aug 2010 12:58:54 +1000
Subject: [Python-Dev] Proposed tweaks to functools.wraps
In-Reply-To: <4C620F63.6050807@netwok.org>
References: <AANLkTimQhkeUWHBLrsmW+JDOMimgjnpxihUh1L894Zoz@mail.gmail.com>
	<4C620F63.6050807@netwok.org>
Message-ID: <AANLkTinwMmqa5h9wAWbCrnyby1vappwN5AmJDcpD0HTp@mail.gmail.com>

On Wed, Aug 11, 2010 at 12:48 PM, ?ric Araujo <merwok at netwok.org> wrote:
>> The second (#9396) came up in the context of the new cache decorators
>> added to functools, and allowing applications to choose their own
>> caching strategies. I suggested exposing the original (uncached)
>> function, and Raymond suggested that the easiest way to enable that
>> would be for functools.update_wrapper to add a new attribute that
>> provides a reference to the original function.
>
> I moved this feature request to its own bug after brief IRC discussion
> with RDM: http://bugs.python.org/issue9567
>
> The idea was to separate concerns and eventually get feedback from
> people reading new-bugs-announce, but your email actually does that :)
>
> I say ?add attribute to partial objects? in the bug title since I don?t
> know if it?s feasible in wraps only; while update_wrapper is simple
> Python code, wraps merely delegates to _functools.partial, so please
> change the title (and maybe add easy keyword) if appropriate.

Ah, that's the trick though - the partial object is the *decorator*,
so when you write

@wraps(f)
def wrapper:
   # ....

it is equivalent to:

def wrapper:
   # ....

wrapper = partial(update_wrapper, wrapped=f)(wrapper)

The partial object is a transient thing during the decoration process
- the wrapper function itself is the object that persists.

So it's only update_wrapper that needs changing to add the new attribute.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From ncoghlan at gmail.com  Wed Aug 11 05:06:59 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 11 Aug 2010 13:06:59 +1000
Subject: [Python-Dev] Proposed tweaks to functools.wraps
In-Reply-To: <AANLkTikzBmQcdiLP+oDzeCd9jO4bzuN7msjs9=MfmTXb@mail.gmail.com>
References: <AANLkTimQhkeUWHBLrsmW+JDOMimgjnpxihUh1L894Zoz@mail.gmail.com>
	<AANLkTikzBmQcdiLP+oDzeCd9jO4bzuN7msjs9=MfmTXb@mail.gmail.com>
Message-ID: <AANLkTimyo4mXSuJ=i34FcTA2tweVR32ui5v98-5Rf4Xt@mail.gmail.com>

On Wed, Aug 11, 2010 at 12:39 PM, Benjamin Peterson <benjamin at python.org> wrote:
>> The second (#9396) came up in the context of the new cache decorators
>> added to functools, and allowing applications to choose their own
>> caching strategies. I suggested exposing the original (uncached)
>> function, and Raymond suggested that the easiest way to enable that
>> would be for functools.update_wrapper to add a new attribute that
>> provides a reference to the original function. Some time back, we
>> considered doing this automatically as an integral part of decoration,
>> but decided that wasn't appropriate. However, building it into the
>> explicit wrapping functions makes sense to me. To avoid namespace
>> conflicts, I plan to use "__wraps__" as the name for the reference to
>> the original function.
>
> Namespace conflict with what? I would prefer "wraps" unless it's
> standardized as a behavior for all decorators.

With any existing attributes on the function - there's a reason
update_wrapper includes a call to __dict__.update(). Using a normal
attribute means having to consider the implications of what to do if
the object being wrapped already has an attribute with that name. By
using a system-reserved name, we can duck that question entirely.

My recollection of previous discussions is that the reason we didn't
make it an implicit part of the decoration process is because not all
decoration is about creating wrapper functions, so it gets messy
trying to decide whether or not it should be added. The explicit use
of the @wraps decorator when creating the wrapper function resolves
that particular concern nicely.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From ncoghlan at gmail.com  Wed Aug 11 05:10:28 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 11 Aug 2010 13:10:28 +1000
Subject: [Python-Dev] Proposed tweaks to functools.wraps
In-Reply-To: <AANLkTikzBmQcdiLP+oDzeCd9jO4bzuN7msjs9=MfmTXb@mail.gmail.com>
References: <AANLkTimQhkeUWHBLrsmW+JDOMimgjnpxihUh1L894Zoz@mail.gmail.com>
	<AANLkTikzBmQcdiLP+oDzeCd9jO4bzuN7msjs9=MfmTXb@mail.gmail.com>
Message-ID: <AANLkTim6z1K3YMKT8aPVuaiPVbV_K=gua+_FNOYJCqsB@mail.gmail.com>

On Wed, Aug 11, 2010 at 12:39 PM, Benjamin Peterson <benjamin at python.org> wrote:
> which would require ignoring the absence of __annotations__.

It turns out the patch that added __annotations__ support also made a
change to make all of the copied attributes optional.

So I'll be tidying up the implementation of that, extending it to the
updated attributes and adding unit tests to make sure they're all
optional.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From steve at holdenweb.com  Wed Aug 11 05:22:34 2010
From: steve at holdenweb.com (Steve Holden)
Date: Tue, 10 Aug 2010 23:22:34 -0400
Subject: [Python-Dev] Proposed tweaks to functools.wraps
In-Reply-To: <AANLkTinwMmqa5h9wAWbCrnyby1vappwN5AmJDcpD0HTp@mail.gmail.com>
References: <AANLkTimQhkeUWHBLrsmW+JDOMimgjnpxihUh1L894Zoz@mail.gmail.com>	<4C620F63.6050807@netwok.org>
	<AANLkTinwMmqa5h9wAWbCrnyby1vappwN5AmJDcpD0HTp@mail.gmail.com>
Message-ID: <i3t521$ehl$1@dough.gmane.org>

On 8/10/2010 10:58 PM, Nick Coghlan wrote:
> On Wed, Aug 11, 2010 at 12:48 PM, ?ric Araujo <merwok at netwok.org> wrote:
>>> The second (#9396) came up in the context of the new cache decorators
>>> added to functools, and allowing applications to choose their own
>>> caching strategies. I suggested exposing the original (uncached)
>>> function, and Raymond suggested that the easiest way to enable that
>>> would be for functools.update_wrapper to add a new attribute that
>>> provides a reference to the original function.
>>
>> I moved this feature request to its own bug after brief IRC discussion
>> with RDM: http://bugs.python.org/issue9567
>>
>> The idea was to separate concerns and eventually get feedback from
>> people reading new-bugs-announce, but your email actually does that :)
>>
>> I say ?add attribute to partial objects? in the bug title since I don?t
>> know if it?s feasible in wraps only; while update_wrapper is simple
>> Python code, wraps merely delegates to _functools.partial, so please
>> change the title (and maybe add easy keyword) if appropriate.
> 
> Ah, that's the trick though - the partial object is the *decorator*,
> so when you write
> 
> @wraps(f)
> def wrapper:
>    # ....
> 
> it is equivalent to:
> 
> def wrapper:
>    # ....
> 
> wrapper = partial(update_wrapper, wrapped=f)(wrapper)
> 
> The partial object is a transient thing during the decoration process
> - the wrapper function itself is the object that persists.
> 
> So it's only update_wrapper that needs changing to add the new attribute.
> 
One of the things that's slightly irking about the decorator syntax is
that a decorator is always called with exactly one argument, and that if
you want to write a parameterized decorator you therefore end up writing
a function that returns a function that returns a function.

I've scratched my head about how partials (or indeed anything else)
could be used to make the extra level of indirection necessary, but
haven' come up with anything that even I could regard as acceptable. But
I can't escape this feeling that there must be a way.

regards
 Steve
-- 
Steve Holden           +1 571 484 6266   +1 800 494 3119
DjangoCon US September 7-9, 2010    http://djangocon.us/
See Python Video!       http://python.mirocommunity.org/
Holden Web LLC                 http://www.holdenweb.com/


From guido at python.org  Wed Aug 11 05:55:56 2010
From: guido at python.org (Guido van Rossum)
Date: Tue, 10 Aug 2010 20:55:56 -0700
Subject: [Python-Dev] Proposed tweaks to functools.wraps
In-Reply-To: <i3t521$ehl$1@dough.gmane.org>
References: <AANLkTimQhkeUWHBLrsmW+JDOMimgjnpxihUh1L894Zoz@mail.gmail.com> 
	<4C620F63.6050807@netwok.org>
	<AANLkTinwMmqa5h9wAWbCrnyby1vappwN5AmJDcpD0HTp@mail.gmail.com> 
	<i3t521$ehl$1@dough.gmane.org>
Message-ID: <AANLkTikJ0kJrSwmyEnxC5qEOO3F9Um9-gX61ZsmGPCC_@mail.gmail.com>

On Tue, Aug 10, 2010 at 8:22 PM, Steve Holden <steve at holdenweb.com> wrote:
> One of the things that's slightly irking about the decorator syntax is
> that a decorator is always called with exactly one argument, and that if
> you want to write a parameterized decorator you therefore end up writing
> a function that returns a function that returns a function.
>
> I've scratched my head about how partials (or indeed anything else)
> could be used to make the extra level of indirection necessary, but
> haven' come up with anything that even I could regard as acceptable. But
> I can't escape this feeling that there must be a way.

Someone at EuroPython brought up this very criticism.

But my argument against it is: you should be able to write either

  @bar(args)
  def func(): ...

or

  foo = bar(args)
  @foo
  def func(): ...

and you should be able to predict how these two relate using standard
knowledge about what it means to say

  foo = bar(args)

and then use foo in an expression. That pretty much rules out
solutions using partial IMO. (Not that I mind -- I find examples using
partial as hard to read as code using reduce()... :-)

-- 
--Guido van Rossum (python.org/~guido)

From ncoghlan at gmail.com  Wed Aug 11 06:43:40 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 11 Aug 2010 14:43:40 +1000
Subject: [Python-Dev] Proposed tweaks to functools.wraps
In-Reply-To: <i3t521$ehl$1@dough.gmane.org>
References: <AANLkTimQhkeUWHBLrsmW+JDOMimgjnpxihUh1L894Zoz@mail.gmail.com>
	<4C620F63.6050807@netwok.org>
	<AANLkTinwMmqa5h9wAWbCrnyby1vappwN5AmJDcpD0HTp@mail.gmail.com>
	<i3t521$ehl$1@dough.gmane.org>
Message-ID: <AANLkTikjBA_T7Y8YQcoowF-tb-UmF7EOhfiWAqERa+Uq@mail.gmail.com>

On Wed, Aug 11, 2010 at 1:22 PM, Steve Holden <steve at holdenweb.com> wrote:
> One of the things that's slightly irking about the decorator syntax is
> that a decorator is always called with exactly one argument, and that if
> you want to write a parameterized decorator you therefore end up writing
> a function that returns a function that returns a function.
>
> I've scratched my head about how partials (or indeed anything else)
> could be used to make the extra level of indirection necessary, but
> haven' come up with anything that even I could regard as acceptable. But
> I can't escape this feeling that there must be a way.

Making the parameterised decorator a callable rather than a function
can sometimes help, provided there are only a few parameters actually
needed in the wrapper function.

Making parameterised decorators easier to parse mentally was pointed
out [1] as a possible benefit of pursuing PEP 3150 (statement local
namespaces). That PEP as a whole is still sitting in "not enough
practical benefit to justify the pain" territory though.

Cheers,
Nick.

[1]  http://mail.python.org/pipermail/python-ideas/2010-July/007691.html

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From tjreedy at udel.edu  Wed Aug 11 08:13:32 2010
From: tjreedy at udel.edu (Terry Reedy)
Date: Wed, 11 Aug 2010 02:13:32 -0400
Subject: [Python-Dev] r83893 - python/branches/release27-maint/Misc/ACKS
In-Reply-To: <4C61D2C5.8050806@v.loewis.de>
References: <20100809161007.81567EE9F7@mail.python.org>	<AANLkTimWa_M_Zzt+QJEkTvr7ijY9yCYsR6afVUci1z1x@mail.gmail.com>	<AANLkTin5yFjNMCBYxV2+dMsNdB95bt_z3zOiVdG=jQJr@mail.gmail.com>	<874of2ew2x.fsf@uwakimon.sk.tsukuba.ac.jp>	<AANLkTimeKq6H9qh3=c1PpbgC8k0H12sFHze3DBE-72qu@mail.gmail.com>	<i3s940$ino$1@dough.gmane.org>
	<4C61D2C5.8050806@v.loewis.de>
Message-ID: <i3tf2c$5vk$1@dough.gmane.org>

On 8/10/2010 6:29 PM, "Martin v. L?wis" wrote:
>
>> If I were committing a patch and was checking to see whether a name that
>> started with a decorated A (or any other letter) were already in the
>> list, I would look in the appropriate place in the A (or other) section,
>> not after Z.
>>
>> Everyone working on the English-based Python distribution knows the
>> order of the 26 English letters. Please use that order (including for
>> decorated versions and tranliterations) instead of various idiosyncratic
>> and possibly conflicting nationality-based rules.
>
> So where do you put ???????? ?????????????

As I said above, where the transliterated version Geor.. goes,
with the tranliteration followed by '(???????? ????????????)' as I 
suggested elsewhere

-- 
Terry Jan Reedy



From ziade.tarek at gmail.com  Wed Aug 11 09:20:13 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 11 Aug 2010 09:20:13 +0200
Subject: [Python-Dev] r83893 - python/branches/release27-maint/Misc/ACKS
In-Reply-To: <AANLkTim5khHr-MUtnf6esD--CSNfM8yKK+EN50s1AGF7@mail.gmail.com>
References: <20100809161007.81567EE9F7@mail.python.org>
	<AANLkTimWa_M_Zzt+QJEkTvr7ijY9yCYsR6afVUci1z1x@mail.gmail.com>
	<AANLkTin5yFjNMCBYxV2+dMsNdB95bt_z3zOiVdG=jQJr@mail.gmail.com>
	<874of2ew2x.fsf@uwakimon.sk.tsukuba.ac.jp>
	<AANLkTimeKq6H9qh3=c1PpbgC8k0H12sFHze3DBE-72qu@mail.gmail.com>
	<i3s940$ino$1@dough.gmane.org> <4C61D2C5.8050806@v.loewis.de>
	<AANLkTimSEnQe53Cq=K_0uzmnDdOBMrdF_1sDuo4JPPJZ@mail.gmail.com>
	<4C61D79D.1080907@v.loewis.de>
	<AANLkTim5khHr-MUtnf6esD--CSNfM8yKK+EN50s1AGF7@mail.gmail.com>
Message-ID: <AANLkTiki-r5A7_k8r8v=JPx5u3DAb3prqm5npiTNfJn6@mail.gmail.com>

On Wed, Aug 11, 2010 at 12:56 AM, Alexander Belopolsky
<alexander.belopolsky at gmail.com> wrote:
..
>
> BTW, does anybody know if
>
> Jiba = Jean-Baptiste LAMY ("Jiba")?

Yes that's it. He work on Soya 3d

From solipsis at pitrou.net  Wed Aug 11 12:45:51 2010
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 11 Aug 2010 12:45:51 +0200
Subject: [Python-Dev] Proposed tweaks to functools.wraps
References: <AANLkTimQhkeUWHBLrsmW+JDOMimgjnpxihUh1L894Zoz@mail.gmail.com>
Message-ID: <20100811124551.58ce763f@pitrou.net>

On Wed, 11 Aug 2010 12:30:40 +1000
Nick Coghlan <ncoghlan at gmail.com> wrote:
> 
> The second (#9396) came up in the context of the new cache decorators
> added to functools, and allowing applications to choose their own
> caching strategies. I suggested exposing the original (uncached)
> function, and Raymond suggested that the easiest way to enable that
> would be for functools.update_wrapper to add a new attribute that
> provides a reference to the original function. Some time back, we
> considered doing this automatically as an integral part of decoration,
> but decided that wasn't appropriate. However, building it into the
> explicit wrapping functions makes sense to me. To avoid namespace
> conflicts, I plan to use "__wraps__" as the name for the reference to
> the original function.

I think it should be "__wrapped__".

Regards

Antoine.



From hodgestar+pythondev at gmail.com  Wed Aug 11 13:26:56 2010
From: hodgestar+pythondev at gmail.com (Simon Cross)
Date: Wed, 11 Aug 2010 13:26:56 +0200
Subject: [Python-Dev] Proposed tweaks to functools.wraps
In-Reply-To: <AANLkTikzBmQcdiLP+oDzeCd9jO4bzuN7msjs9=MfmTXb@mail.gmail.com>
References: <AANLkTimQhkeUWHBLrsmW+JDOMimgjnpxihUh1L894Zoz@mail.gmail.com>
	<AANLkTikzBmQcdiLP+oDzeCd9jO4bzuN7msjs9=MfmTXb@mail.gmail.com>
Message-ID: <AANLkTikxoNKPrV3HbPtV2Hxa9Z5sE++443CsmvZ8_jJw@mail.gmail.com>

On Wed, Aug 11, 2010 at 4:39 AM, Benjamin Peterson <benjamin at python.org> wrote:
> Namespace conflict with what? I would prefer "wraps" unless it's
> standardized as a behavior for all decorators.

Having the original function available as __wrapped__ would be really
cool, although I'm not quite sure what the behaviour should be in
corner cases like:

* The decorator returns the original function (I suppose a reference
to itself is okay?)
* The decorator returns the a function that is already decorating
something else.

Schiavo
Simon

From ncoghlan at gmail.com  Wed Aug 11 14:28:00 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 11 Aug 2010 22:28:00 +1000
Subject: [Python-Dev] Proposed tweaks to functools.wraps
In-Reply-To: <AANLkTikxoNKPrV3HbPtV2Hxa9Z5sE++443CsmvZ8_jJw@mail.gmail.com>
References: <AANLkTimQhkeUWHBLrsmW+JDOMimgjnpxihUh1L894Zoz@mail.gmail.com>
	<AANLkTikzBmQcdiLP+oDzeCd9jO4bzuN7msjs9=MfmTXb@mail.gmail.com>
	<AANLkTikxoNKPrV3HbPtV2Hxa9Z5sE++443CsmvZ8_jJw@mail.gmail.com>
Message-ID: <AANLkTimDh0335DMWGxRxaN3u3ekmnhnbYJPDvLGkNfpN@mail.gmail.com>

On Wed, Aug 11, 2010 at 9:26 PM, Simon Cross
<hodgestar+pythondev at gmail.com> wrote:
> On Wed, Aug 11, 2010 at 4:39 AM, Benjamin Peterson <benjamin at python.org> wrote:
>> Namespace conflict with what? I would prefer "wraps" unless it's
>> standardized as a behavior for all decorators.
>
> Having the original function available as __wrapped__ would be really
> cool, although I'm not quite sure what the behaviour should be in
> corner cases like:
>
> * The decorator returns the original function (I suppose a reference
> to itself is okay?)
> * The decorator returns the a function that is already decorating
> something else.

Those are the corner cases that make it more appropriate to have this
as a behaviour of functools.update_wrapper() (and hence the
functools.wraps() decorator) rather than built in to the decorator
machinery.

The change will just add the following line to update_wrapper():

  wrapper.__wrapped__ = wrapped

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From ncoghlan at gmail.com  Wed Aug 11 14:28:55 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 11 Aug 2010 22:28:55 +1000
Subject: [Python-Dev] Proposed tweaks to functools.wraps
In-Reply-To: <20100811124551.58ce763f@pitrou.net>
References: <AANLkTimQhkeUWHBLrsmW+JDOMimgjnpxihUh1L894Zoz@mail.gmail.com>
	<20100811124551.58ce763f@pitrou.net>
Message-ID: <AANLkTikJTQMM01NGkCcBs5pbEPcb9YDemT1_9VyeQPF3@mail.gmail.com>

On Wed, Aug 11, 2010 at 8:45 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Wed, 11 Aug 2010 12:30:40 +1000
> Nick Coghlan <ncoghlan at gmail.com> wrote:
>>
>> The second (#9396) came up in the context of the new cache decorators
>> added to functools, and allowing applications to choose their own
>> caching strategies. I suggested exposing the original (uncached)
>> function, and Raymond suggested that the easiest way to enable that
>> would be for functools.update_wrapper to add a new attribute that
>> provides a reference to the original function. Some time back, we
>> considered doing this automatically as an integral part of decoration,
>> but decided that wasn't appropriate. However, building it into the
>> explicit wrapping functions makes sense to me. To avoid namespace
>> conflicts, I plan to use "__wraps__" as the name for the reference to
>> the original function.
>
> I think it should be "__wrapped__".

Agreed, particularly since the relevant argument to update_wrapper()
is already called "wrapped".

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From steve at pearwood.info  Wed Aug 11 15:00:29 2010
From: steve at pearwood.info (Steven D'Aprano)
Date: Wed, 11 Aug 2010 23:00:29 +1000
Subject: [Python-Dev] Proposed tweaks to functools.wraps
In-Reply-To: <AANLkTikxoNKPrV3HbPtV2Hxa9Z5sE++443CsmvZ8_jJw@mail.gmail.com>
References: <AANLkTimQhkeUWHBLrsmW+JDOMimgjnpxihUh1L894Zoz@mail.gmail.com>
	<AANLkTikzBmQcdiLP+oDzeCd9jO4bzuN7msjs9=MfmTXb@mail.gmail.com>
	<AANLkTikxoNKPrV3HbPtV2Hxa9Z5sE++443CsmvZ8_jJw@mail.gmail.com>
Message-ID: <201008112300.30677.steve@pearwood.info>

On Wed, 11 Aug 2010 09:26:56 pm Simon Cross wrote:
> On Wed, Aug 11, 2010 at 4:39 AM, Benjamin Peterson 
<benjamin at python.org> wrote:
> > Namespace conflict with what? I would prefer "wraps" unless it's
> > standardized as a behavior for all decorators.
>
> Having the original function available as __wrapped__ would be really
> cool, although I'm not quite sure what the behaviour should be in
> corner cases like:
>
> * The decorator returns the original function (I suppose a reference
> to itself is okay?)

There's no reason why a function can't have an attribute that refers to 
the function itself. It works fine:

>>> def f():
...     return f.__wrapped__
...
>>> f.__wrapped__ = f
>>>
>>> f() is f
True

But in the case of a decorator returning the original function, the 
point is moot. If the original function is returned, then it hasn't 
been decorated at all, so there shouldn't be a __wrapped__ attribute 
added:

def decorator(func):
    if not __debug__:
        # Return undecorated original.
        return func  
    @wraps(func)
    def inner(*args):
        print args
        return func(*args)
    return inner



> * The decorator returns the a function that is already decorating
> something else.

That shouldn't make any difference. Given:

@wraps(f)
def func(*args):
    do_something()
    return f(*args)

then func.__wrapped__ gives f. If f itself wraps (say) g, and g wraps h, 
then you have:

func.__wrapped__ => f
func.__wrapped__.__wrapped__ => g
func.__wrapped__.__wrapped__.__wrapped__ => h

and so on, until you reach a function that doesn't wrap anything and 
doesn't have a __wrapped__ attribute.


I'm +1 on the proposal.



-- 
Steven D'Aprano

From sturla at molden.no  Wed Aug 11 15:21:15 2010
From: sturla at molden.no (Sturla Molden)
Date: Wed, 11 Aug 2010 15:21:15 +0200
Subject: [Python-Dev] mingw support?
In-Reply-To: <AANLkTik0QoHNXGgqhbtQKJqrFoC3kxzzomm06sJfZLJ8@mail.gmail.com>
References: <20100807195541.GA13990@laptop.gs> <i3n225$osp$1@dough.gmane.org>
	<AANLkTi=dc=0brYo34=xaU6D9wH97eB_tTN=b=FBNjLNh@mail.gmail.com>
	<9f2ea5ad00140f45fdf639eb0b234aea.squirrel@webmail.uio.no>
	<i3q110$ncr$1@dough.gmane.org> <20100810140620.GB4464@laptop.gs>
	<AANLkTik0QoHNXGgqhbtQKJqrFoC3kxzzomm06sJfZLJ8@mail.gmail.com>
Message-ID: <40b838e9eeeac1852e96a0f5d25d67a0.squirrel@webmail.uio.no>


"David Cournapeau":
> Autotools only help for posix-like platforms. They are certainly a big
> hindrance on windows platform in general,

That is why mingw has MSYS.

mingw is not just a gcc port, but also a miniature gnu environment for
windows. MSYS' bash shell allows us to do things like:

$ ./configure
$ make && make install



Sturla


From solipsis at pitrou.net  Wed Aug 11 15:35:16 2010
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 11 Aug 2010 15:35:16 +0200
Subject: [Python-Dev] r83893 - python/branches/release27-maint/Misc/ACKS
References: <20100809161007.81567EE9F7@mail.python.org>
	<AANLkTimWa_M_Zzt+QJEkTvr7ijY9yCYsR6afVUci1z1x@mail.gmail.com>
	<AANLkTin5yFjNMCBYxV2+dMsNdB95bt_z3zOiVdG=jQJr@mail.gmail.com>
	<874of2ew2x.fsf@uwakimon.sk.tsukuba.ac.jp>
	<AANLkTimeKq6H9qh3=c1PpbgC8k0H12sFHze3DBE-72qu@mail.gmail.com>
	<i3s940$ino$1@dough.gmane.org>
Message-ID: <20100811153516.3d3dd95b@pitrou.net>

On Tue, 10 Aug 2010 15:25:52 -0400
Terry Reedy <tjreedy at udel.edu> wrote:
> 
> Everyone working on the English-based Python distribution knows the 
> order of the 26 English letters.

How does that solve anything?

I just had to decide whether ?Jason V. Miller? had to come before or
after ?Jay T. Miller? ('Jason' < 'Jay' but 'V' > 'T'). Knowledge of the
?English? alphabet isn't enough to make a resolution: an idiosyncratic
rule is still needed.
(and before you claim that rule is well-known: I had to ask)

Regards

Antoine.



From hodgestar+pythondev at gmail.com  Wed Aug 11 16:12:11 2010
From: hodgestar+pythondev at gmail.com (Simon Cross)
Date: Wed, 11 Aug 2010 16:12:11 +0200
Subject: [Python-Dev] Proposed tweaks to functools.wraps
In-Reply-To: <201008112300.30677.steve@pearwood.info>
References: <AANLkTimQhkeUWHBLrsmW+JDOMimgjnpxihUh1L894Zoz@mail.gmail.com>
	<AANLkTikzBmQcdiLP+oDzeCd9jO4bzuN7msjs9=MfmTXb@mail.gmail.com>
	<AANLkTikxoNKPrV3HbPtV2Hxa9Z5sE++443CsmvZ8_jJw@mail.gmail.com>
	<201008112300.30677.steve@pearwood.info>
Message-ID: <AANLkTim=oLuHYQ_7gjJE5LFc4LnJ0HhCTHP63Vy+BzDW@mail.gmail.com>

On Wed, Aug 11, 2010 at 3:00 PM, Steven D'Aprano <steve at pearwood.info> wrote:
>> * The decorator returns the original function (I suppose a reference
>> to itself is okay?)
>
> There's no reason why a function can't have an attribute that refers to
> the function itself. It works fine:

Yes. But it's more common for the original function to have be
modified in some way. e.g.:

def autodoc(f):
    f.__doc__ += document_args(f)
    return f

@autodoc
def f(x, y):
     """Add two numbers"""
     return x + y

And then f.__wrapped__ is not particularly useful because the original
function no longer exists and odd things will happen. For example, in
the code above autodoc(f.__wrapped__).__doc__ will not equal
f.__doc__.

>> * The decorator returns the a function that is already decorating
>> something else.
>
> That shouldn't make any difference. Given:
>
> @wraps(f)
> def func(*args):
> ? ?do_something()
> ? ?return f(*args)
>
> then func.__wrapped__ gives f. If f itself wraps (say) g, and g wraps h,
> then you have:

I guess my description of the problem wasn't clear. I meant:

def _debug(*args, **kwargs)
    print args, kwargs

def mock(f):
    return _debug

@mock
def plus(a, b):
   return a + b

@mock
def prod(a, b):
    return a * b

Schiavo
Simon

From mail at timgolden.me.uk  Wed Aug 11 16:21:00 2010
From: mail at timgolden.me.uk (Tim Golden)
Date: Wed, 11 Aug 2010 15:21:00 +0100
Subject: [Python-Dev] New Summary Lists on Issue Tracker
Message-ID: <4C62B1CC.5040902@timgolden.me.uk>

Thanks to whoever's been working on the new Summary lists on the Issue 
Tracker.
The "Followed by you" / "Created by you" / "Assigned to you" are just what
the doctor ordered.

TJG

From ysj.ray at gmail.com  Wed Aug 11 16:38:30 2010
From: ysj.ray at gmail.com (Ray Allen)
Date: Wed, 11 Aug 2010 22:38:30 +0800
Subject: [Python-Dev] Proposed tweaks to functools.wraps
In-Reply-To: <AANLkTim=oLuHYQ_7gjJE5LFc4LnJ0HhCTHP63Vy+BzDW@mail.gmail.com>
References: <AANLkTimQhkeUWHBLrsmW+JDOMimgjnpxihUh1L894Zoz@mail.gmail.com>
	<AANLkTikzBmQcdiLP+oDzeCd9jO4bzuN7msjs9=MfmTXb@mail.gmail.com>
	<AANLkTikxoNKPrV3HbPtV2Hxa9Z5sE++443CsmvZ8_jJw@mail.gmail.com>
	<201008112300.30677.steve@pearwood.info>
	<AANLkTim=oLuHYQ_7gjJE5LFc4LnJ0HhCTHP63Vy+BzDW@mail.gmail.com>
Message-ID: <AANLkTi=VZxuwTd=SUB3DKd8OyfnXYKmzf61C=RkXC5Q6@mail.gmail.com>

I think this is a good idea, because sometimes getting the innermost wrapped
function from a wrapper function is very useful. For example, when I use
inspect.getsource(), in most case, I want to get the source code of the
wrapped function, not the wrapper, because the wrapped function usually
contains the most important code. Even further, we can add optional keyword
argument to let the functions in inspect module to get the wrapped function
instead of the wrapper function by following the __wrapped__ chain
automatically.


-- 
Ray Allen
Best wishes!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100811/077314aa/attachment.html>

From dickinsm at gmail.com  Wed Aug 11 16:59:45 2010
From: dickinsm at gmail.com (Mark Dickinson)
Date: Wed, 11 Aug 2010 15:59:45 +0100
Subject: [Python-Dev] New Summary Lists on Issue Tracker
In-Reply-To: <4C62B1CC.5040902@timgolden.me.uk>
References: <4C62B1CC.5040902@timgolden.me.uk>
Message-ID: <AANLkTiko-a2jzTPLdZxqYsPd8+BhcquvmfuB0LnZ4Q0k@mail.gmail.com>

On Wed, Aug 11, 2010 at 3:21 PM, Tim Golden <mail at timgolden.me.uk> wrote:
> Thanks to whoever's been working on the new Summary lists on the Issue
> Tracker.

Ezio Melotti, I assume.

> The "Followed by you" / "Created by you" / "Assigned to you" are just what
> the doctor ordered.

Agreed.  Now I can get rid of my own equivalent custom searches. :)

One niggle:  we seem to have lost the simple 'Open Issues' search
under 'Summaries' on the left-hand side of the page.  This feels a bit
odd, given that it's what's displayed by default when a non-registered
user goes to http://bugs.python.org.  If that non-registered user then
clicks on something else, like 'easy issues', there doesn't seem to be
any easy way (that I can see) to go back to the original list of all
open issues.

Of course, as a registered user, I can add my own custom search for
that if I want it.  But I can't help feeling that non-registered users
might miss this.

Mark

From ezio.melotti at gmail.com  Wed Aug 11 17:09:11 2010
From: ezio.melotti at gmail.com (Ezio Melotti)
Date: Wed, 11 Aug 2010 18:09:11 +0300
Subject: [Python-Dev] New Summary Lists on Issue Tracker
In-Reply-To: <AANLkTiko-a2jzTPLdZxqYsPd8+BhcquvmfuB0LnZ4Q0k@mail.gmail.com>
References: <4C62B1CC.5040902@timgolden.me.uk>
	<AANLkTiko-a2jzTPLdZxqYsPd8+BhcquvmfuB0LnZ4Q0k@mail.gmail.com>
Message-ID: <4C62BD17.3010605@gmail.com>

  On 11/08/2010 17.59, Mark Dickinson wrote:
> On Wed, Aug 11, 2010 at 3:21 PM, Tim Golden<mail at timgolden.me.uk>  wrote:
>> Thanks to whoever's been working on the new Summary lists on the Issue
>> Tracker.
> Ezio Melotti, I assume.

Yes :)
(see http://psf.upfronthosting.co.za/roundup/meta/issue329)

>> The "Followed by you" / "Created by you" / "Assigned to you" are just what
>> the doctor ordered.
> Agreed.  Now I can get rid of my own equivalent custom searches. :)
>
> One niggle:  we seem to have lost the simple 'Open Issues' search
> under 'Summaries' on the left-hand side of the page.

I was expecting someone to complain about it.

> This feels a bit
> odd, given that it's what's displayed by default when a non-registered
> user goes to http://bugs.python.org.  If that non-registered user then
> clicks on something else, like 'easy issues', there doesn't seem to be
> any easy way (that I can see) to go back to the original list of all
> open issues.

There actually is an easy way: the big python logo on the top left of 
the page.
However I understand that this is not so obvious, so I can either add 
back the 'open issues' link or try to make it more obvious.

> Of course, as a registered user, I can add my own custom search for
> that if I want it.  But I can't help feeling that non-registered users
> might miss this.
>
> Mark

Best Regards,
Ezio Melotti

From merwok at netwok.org  Wed Aug 11 17:22:05 2010
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Wed, 11 Aug 2010 17:22:05 +0200
Subject: [Python-Dev] Fixing #7175: a standard location for Python config
	files
Message-ID: <4C62C01D.6000900@netwok.org>

Hello list

Tarek opened a distutils bugs in http://bugs.python.org/issue7175 that
evolved into a discussion about the proper location to use for config files.

Distutils uses [.]pydistutils.cfg and .pypirc, and now unittest2 has a
config file too.

It would be nice to define one standard location for config files used
by stdlib modules, and maybe also by third-party programs related
closely to Python development (testing tools, static code checkers and
the like), in a way that doesn?t clutter the user home directory with a
dozen dotfiles while still being easily found.

(The Unix notions of dotfiles and home directory have to be adapted to
use non-dotfiles in some standard place on various Windows. The Mac
experts disagree on the right directory to use.)

Tarek, Antoine, RDM, MAL were +1 on using ~/.python (whether to use
.pythonx.y or .python/x.y is a subissue to discuss after general agreement).

What do you think about this?

Regards


From dickinsm at gmail.com  Wed Aug 11 17:28:40 2010
From: dickinsm at gmail.com (Mark Dickinson)
Date: Wed, 11 Aug 2010 16:28:40 +0100
Subject: [Python-Dev] New Summary Lists on Issue Tracker
In-Reply-To: <4C62BD17.3010605@gmail.com>
References: <4C62B1CC.5040902@timgolden.me.uk>
	<AANLkTiko-a2jzTPLdZxqYsPd8+BhcquvmfuB0LnZ4Q0k@mail.gmail.com>
	<4C62BD17.3010605@gmail.com>
Message-ID: <AANLkTimFm4ukA1Xfo9T6o_SZisXy=hqv8W+mCA1x_YHj@mail.gmail.com>

On Wed, Aug 11, 2010 at 4:09 PM, Ezio Melotti <ezio.melotti at gmail.com> wrote:
> ?On 11/08/2010 17.59, Mark Dickinson wrote:
>> One niggle: ?we seem to have lost the simple 'Open Issues' search
>> under 'Summaries' on the left-hand side of the page.
>
> I was expecting someone to complain about it.

Glad to oblige. :)

> There actually is an easy way: the big python logo on the top left of the
> page.

Ah yes---that does indeed work.  Thanks!

> However I understand that this is not so obvious

Well, it wasn't obvious to me, at least.  If I'd thought about it, I
probably would have expected that logo to take me back to the
top-level python.org site.

> so I can either add back the 'open issues' link or try to make it more obvious.

Well, perhaps I'm the only person bothered by this (and when I say
'bothered', it's not exactly keeping me up at nights).  So
unless/until there's evidence that others would like it restored, I
wouldn't worry about it.

In any case, thanks for all the b.p.o. improvements!

Mark

From fuzzyman at voidspace.org.uk  Wed Aug 11 17:35:58 2010
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Wed, 11 Aug 2010 16:35:58 +0100
Subject: [Python-Dev] Fixing #7175: a standard location for Python
 config files
In-Reply-To: <4C62C01D.6000900@netwok.org>
References: <4C62C01D.6000900@netwok.org>
Message-ID: <4C62C35E.3070904@voidspace.org.uk>

On 11/08/2010 16:22, ?ric Araujo wrote:
> Hello list
>
> Tarek opened a distutils bugs in http://bugs.python.org/issue7175 that
> evolved into a discussion about the proper location to use for config files.
>
> Distutils uses [.]pydistutils.cfg and .pypirc, and now unittest2 has a
> config file too.
>    

IDLE has a config directory too - currently .idlerc in ~ (on Mac OS X at 
any rate).

Michael

> It would be nice to define one standard location for config files used
> by stdlib modules, and maybe also by third-party programs related
> closely to Python development (testing tools, static code checkers and
> the like), in a way that doesn?t clutter the user home directory with a
> dozen dotfiles while still being easily found.
>
> (The Unix notions of dotfiles and home directory have to be adapted to
> use non-dotfiles in some standard place on various Windows. The Mac
> experts disagree on the right directory to use.)
>
> Tarek, Antoine, RDM, MAL were +1 on using ~/.python (whether to use
> .pythonx.y or .python/x.y is a subissue to discuss after general agreement).
>
> What do you think about this?
>
> Regards
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at 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/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (?BOGUS AGREEMENTS?) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.



From ronaldoussoren at mac.com  Wed Aug 11 17:45:06 2010
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Wed, 11 Aug 2010 17:45:06 +0200
Subject: [Python-Dev] New Summary Lists on Issue Tracker
In-Reply-To: <4C62B1CC.5040902@timgolden.me.uk>
References: <4C62B1CC.5040902@timgolden.me.uk>
Message-ID: <18F5C880-141A-4C8E-A238-BC95637D5EB3@mac.com>


On 11 Aug, 2010, at 16:21, Tim Golden wrote:

> Thanks to whoever's been working on the new Summary lists on the Issue Tracker.
> The "Followed by you" / "Created by you" / "Assigned to you" are just what
> the doctor ordered.

I'm not quite happy about them because these reports include closed issues which is noise most of the time, and because issues aren't grouped or ordered by priorities.

Ronald

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3567 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100811/359bb356/attachment.bin>

From mail at timgolden.me.uk  Wed Aug 11 17:48:39 2010
From: mail at timgolden.me.uk (Tim Golden)
Date: Wed, 11 Aug 2010 16:48:39 +0100
Subject: [Python-Dev] New Summary Lists on Issue Tracker
In-Reply-To: <18F5C880-141A-4C8E-A238-BC95637D5EB3@mac.com>
References: <4C62B1CC.5040902@timgolden.me.uk>
	<18F5C880-141A-4C8E-A238-BC95637D5EB3@mac.com>
Message-ID: <4C62C657.8000807@timgolden.me.uk>

On 11/08/2010 16:45, Ronald Oussoren wrote:
>
> On 11 Aug, 2010, at 16:21, Tim Golden wrote:
>
>> Thanks to whoever's been working on the new Summary lists on the Issue Tracker.
>> The "Followed by you" / "Created by you" / "Assigned to you" are just what
>> the doctor ordered.
>
> I'm not quite happy about them because these reports include closed issues which is noise most of the time, and because issues aren't grouped or ordered by priorities.

Hadn't noticed that in my enthusiasm about having them at all.

TJG

From linux at gabriel-striewe.de  Wed Aug 11 19:49:43 2010
From: linux at gabriel-striewe.de (linux at gabriel-striewe.de)
Date: Wed, 11 Aug 2010 19:49:43 +0200
Subject: [Python-Dev] mingw support?
In-Reply-To: <40b838e9eeeac1852e96a0f5d25d67a0.squirrel@webmail.uio.no>
References: <20100807195541.GA13990@laptop.gs> <i3n225$osp$1@dough.gmane.org>
	<AANLkTi=dc=0brYo34=xaU6D9wH97eB_tTN=b=FBNjLNh@mail.gmail.com>
	<9f2ea5ad00140f45fdf639eb0b234aea.squirrel@webmail.uio.no>
	<i3q110$ncr$1@dough.gmane.org> <20100810140620.GB4464@laptop.gs>
	<AANLkTik0QoHNXGgqhbtQKJqrFoC3kxzzomm06sJfZLJ8@mail.gmail.com>
	<40b838e9eeeac1852e96a0f5d25d67a0.squirrel@webmail.uio.no>
Message-ID: <20100811174943.GC3683@laptop.gs>

On Wed, Aug 11, 2010 at 03:21:15PM +0200, Sturla Molden wrote:
> 
> "David Cournapeau":
> > Autotools only help for posix-like platforms. They are certainly a big
> > hindrance on windows platform in general,
> 
> That is why mingw has MSYS.
> 
> mingw is not just a gcc port, but also a miniature gnu environment for
> windows. MSYS' bash shell allows us to do things like:
> 
> $ ./configure
> $ make && make install
> 
> 
> 
> Sturla

I will try to compile the python-svn trunk then by using the
autotools plus tdm-gcc (a mingw fork) as well as MSYS. I might try to
report any errors back to the autotools list and sort out with them
what is happening.

Gabriel

From fdrake at acm.org  Wed Aug 11 17:52:48 2010
From: fdrake at acm.org (Fred Drake)
Date: Wed, 11 Aug 2010 11:52:48 -0400
Subject: [Python-Dev] Fixing #7175: a standard location for Python
	config files
In-Reply-To: <4C62C01D.6000900@netwok.org>
References: <4C62C01D.6000900@netwok.org>
Message-ID: <AANLkTimk4Ei85NULF5HYyz=cvuzB6xP6JiAF63+6Z5so@mail.gmail.com>

On Wed, Aug 11, 2010 at 11:22 AM, ?ric Araujo <merwok at netwok.org> wrote:
> Tarek, Antoine, RDM, MAL were +1 on using ~/.python (whether to use
> .pythonx.y or .python/x.y is a subissue to discuss after general agreement).

+0.5

I'd like to see a more complete proposal, including:

- what to do with Windows, Mac OS X

- backward compatibility considered
  (seems straightforward, but seemings are often wrong)

- cross-platform API to locate these files
  (should be able to address the b/w compat issues)

Seems like a good idea to have a "registry" of files known to be placed there
(a wiki page should be sufficient; if the API is used to create the directory,
it can drop in a README.txt pointing to that page).


? -Fred

--
Fred L. Drake, Jr.? ? <fdrake at gmail.com>
"A storm broke loose in my mind."? --Albert Einstein

From fdrake at acm.org  Wed Aug 11 17:55:20 2010
From: fdrake at acm.org (Fred Drake)
Date: Wed, 11 Aug 2010 11:55:20 -0400
Subject: [Python-Dev] New Summary Lists on Issue Tracker
In-Reply-To: <AANLkTimFm4ukA1Xfo9T6o_SZisXy=hqv8W+mCA1x_YHj@mail.gmail.com>
References: <4C62B1CC.5040902@timgolden.me.uk>
	<AANLkTiko-a2jzTPLdZxqYsPd8+BhcquvmfuB0LnZ4Q0k@mail.gmail.com> 
	<4C62BD17.3010605@gmail.com>
	<AANLkTimFm4ukA1Xfo9T6o_SZisXy=hqv8W+mCA1x_YHj@mail.gmail.com>
Message-ID: <AANLkTikccMFQ21Pwh+fAfXS-jwUg9vjKOCy6_6A8x2Sh@mail.gmail.com>

On Wed, Aug 11, 2010 at 11:28 AM, Mark Dickinson <dickinsm at gmail.com> wrote:
> Well, perhaps I'm the only person bothered by this (and when I say
> 'bothered', it's not exactly keeping me up at nights).

I'm not going to lose sleep over it either, but the logo-link is
generally considered very non-discoverable.  Keeping a query in the
sidebar doesn't seem a huge price to pay.


? -Fred

--
Fred L. Drake, Jr.? ? <fdrake at gmail.com>
"A storm broke loose in my mind."? --Albert Einstein

From raymond.hettinger at gmail.com  Wed Aug 11 21:16:54 2010
From: raymond.hettinger at gmail.com (Raymond Hettinger)
Date: Wed, 11 Aug 2010 12:16:54 -0700
Subject: [Python-Dev] Proposed tweaks to functools.wraps
In-Reply-To: <201008112300.30677.steve@pearwood.info>
References: <AANLkTimQhkeUWHBLrsmW+JDOMimgjnpxihUh1L894Zoz@mail.gmail.com>
	<AANLkTikzBmQcdiLP+oDzeCd9jO4bzuN7msjs9=MfmTXb@mail.gmail.com>
	<AANLkTikxoNKPrV3HbPtV2Hxa9Z5sE++443CsmvZ8_jJw@mail.gmail.com>
	<201008112300.30677.steve@pearwood.info>
Message-ID: <5618FDEE-F2BB-488C-8FBB-84CB2A48E39E@gmail.com>


On Aug 11, 2010, at 6:00 AM, Steven D'Aprano wrote:

> @wraps(f)
> def func(*args):
>    do_something()
>    return f(*args)
> 
> then func.__wrapped__ gives f. If f itself wraps (say) g, and g wraps h, 
> then you have:
> 
> func.__wrapped__ => f
> func.__wrapped__.__wrapped__ => g
> func.__wrapped__.__wrapped__.__wrapped__ => h
> 
> and so on, until you reach a function that doesn't wrap anything and 
> doesn't have a __wrapped__ attribute.
> 
> 
> I'm +1 on the proposal.

+1 from me also.

The ability to introspect is basic to Python's design.
Objects know their class, functions know their code objects,
bound methods know both their underlying function, 
classes know their own class dictionary, etc.


Raymond




From ncoghlan at gmail.com  Wed Aug 11 23:12:15 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 12 Aug 2010 07:12:15 +1000
Subject: [Python-Dev] New Summary Lists on Issue Tracker
In-Reply-To: <AANLkTikccMFQ21Pwh+fAfXS-jwUg9vjKOCy6_6A8x2Sh@mail.gmail.com>
References: <4C62B1CC.5040902@timgolden.me.uk>
	<AANLkTiko-a2jzTPLdZxqYsPd8+BhcquvmfuB0LnZ4Q0k@mail.gmail.com>
	<4C62BD17.3010605@gmail.com>
	<AANLkTimFm4ukA1Xfo9T6o_SZisXy=hqv8W+mCA1x_YHj@mail.gmail.com>
	<AANLkTikccMFQ21Pwh+fAfXS-jwUg9vjKOCy6_6A8x2Sh@mail.gmail.com>
Message-ID: <AANLkTinqAzgJhP-q346yA0twYxB-O=uDFNDcN+83CnYK@mail.gmail.com>

On Thu, Aug 12, 2010 at 1:55 AM, Fred Drake <fdrake at acm.org> wrote:
> On Wed, Aug 11, 2010 at 11:28 AM, Mark Dickinson <dickinsm at gmail.com> wrote:
>> Well, perhaps I'm the only person bothered by this (and when I say
>> 'bothered', it's not exactly keeping me up at nights).
>
> I'm not going to lose sleep over it either, but the logo-link is
> generally considered very non-discoverable. ?Keeping a query in the
> sidebar doesn't seem a huge price to pay.

Same here - we aren't *that* pressed for vertical real estate that we
can't afford to keep the explicit search. The mouseover for the logo
isn't particular clear either (since it relies on the fact that "all
open issues" is the default search when you land on bugs.python.org
directly).

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From ncoghlan at gmail.com  Wed Aug 11 23:15:28 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 12 Aug 2010 07:15:28 +1000
Subject: [Python-Dev] New Summary Lists on Issue Tracker
In-Reply-To: <18F5C880-141A-4C8E-A238-BC95637D5EB3@mac.com>
References: <4C62B1CC.5040902@timgolden.me.uk>
	<18F5C880-141A-4C8E-A238-BC95637D5EB3@mac.com>
Message-ID: <AANLkTimbT9pxB8yHeE15wTjQD0UxN6-xaWV0iWL-mp6N@mail.gmail.com>

On Thu, Aug 12, 2010 at 1:45 AM, Ronald Oussoren <ronaldoussoren at mac.com> wrote:
>
> On 11 Aug, 2010, at 16:21, Tim Golden wrote:
>
>> Thanks to whoever's been working on the new Summary lists on the Issue Tracker.
>> The "Followed by you" / "Created by you" / "Assigned to you" are just what
>> the doctor ordered.
>
> I'm not quite happy about them because these reports include closed issues which is noise most of the time, and because issues aren't grouped or ordered by priorities.

I like the new list of standard queries, and don't mind having them
sorted by activity rather than priority. (And with the closed issues
grouped after the open issues, that aspect doesn't really bother me
either).

However, it would be nice to at least have the issue priority
*visible* in the results for these searches. If I want more than that,
it's easy enough to keep my own queries around.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From ncoghlan at gmail.com  Wed Aug 11 23:21:32 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 12 Aug 2010 07:21:32 +1000
Subject: [Python-Dev] Proposed tweaks to functools.wraps
In-Reply-To: <AANLkTim=oLuHYQ_7gjJE5LFc4LnJ0HhCTHP63Vy+BzDW@mail.gmail.com>
References: <AANLkTimQhkeUWHBLrsmW+JDOMimgjnpxihUh1L894Zoz@mail.gmail.com>
	<AANLkTikzBmQcdiLP+oDzeCd9jO4bzuN7msjs9=MfmTXb@mail.gmail.com>
	<AANLkTikxoNKPrV3HbPtV2Hxa9Z5sE++443CsmvZ8_jJw@mail.gmail.com>
	<201008112300.30677.steve@pearwood.info>
	<AANLkTim=oLuHYQ_7gjJE5LFc4LnJ0HhCTHP63Vy+BzDW@mail.gmail.com>
Message-ID: <AANLkTikZ75Vup=gZMuhL0AcB68QwOheJ3YypH-ZCeLtk@mail.gmail.com>

On Thu, Aug 12, 2010 at 12:12 AM, Simon Cross
<hodgestar+pythondev at gmail.com> wrote:
> Yes. But it's more common for the original function to have be
> modified in some way. e.g.:
>
> def autodoc(f):
> ? ?f.__doc__ += document_args(f)
> ? ?return f
>
> @autodoc
> def f(x, y):
> ? ? """Add two numbers"""
> ? ? return x + y
>
> And then f.__wrapped__ is not particularly useful because the original
> function no longer exists and odd things will happen. For example, in
> the code above autodoc(f.__wrapped__).__doc__ will not equal
> f.__doc__.

There's no call to wraps or update_wrapper here, so f.__wrapped__ won't exist.

> I guess my description of the problem wasn't clear. I meant:
>
> def _debug(*args, **kwargs)
> ? ?print args, kwargs
>
> def mock(f):
> ? ?return _debug
>
> @mock
> def plus(a, b):
> ? return a + b
>
> @mock
> def prod(a, b):
> ? ?return a * b

Again, without any calls to wraps or update_wrapper, plus.__wrapped__
and prod.__wrapped__ won't exist.

However, as I noted before, these kinds of scenario are the reason we
decided that building this feature directly into the decorator
machinery wasn't a good idea.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From tjreedy at udel.edu  Wed Aug 11 23:37:24 2010
From: tjreedy at udel.edu (Terry Reedy)
Date: Wed, 11 Aug 2010 17:37:24 -0400
Subject: [Python-Dev] Proposed tweaks to functools.wraps
In-Reply-To: <5618FDEE-F2BB-488C-8FBB-84CB2A48E39E@gmail.com>
References: <AANLkTimQhkeUWHBLrsmW+JDOMimgjnpxihUh1L894Zoz@mail.gmail.com>	<AANLkTikzBmQcdiLP+oDzeCd9jO4bzuN7msjs9=MfmTXb@mail.gmail.com>	<AANLkTikxoNKPrV3HbPtV2Hxa9Z5sE++443CsmvZ8_jJw@mail.gmail.com>	<201008112300.30677.steve@pearwood.info>
	<5618FDEE-F2BB-488C-8FBB-84CB2A48E39E@gmail.com>
Message-ID: <i3v56k$nok$1@dough.gmane.org>

On 8/11/2010 3:16 PM, Raymond Hettinger wrote:

> The ability to introspect is basic to Python's design.
> Objects know their class, functions know their code objects,
> bound methods know both their underlying function,
> classes know their own class dictionary, etc.

Should iterators know their iterable when there is one?

There is or was a request for this on python-list, I believe, a few days 
ago. I suggested bad idea because
a) iterator requirement is intentially minimal
b) not all iterators have underlying object
c) OP wanted to mutate underlying object (list) while iterating
I did give a my_iter class that would do what OP wanted.

-- 
Terry Jan Reedy


From hodgestar+pythondev at gmail.com  Wed Aug 11 23:55:44 2010
From: hodgestar+pythondev at gmail.com (Simon Cross)
Date: Wed, 11 Aug 2010 23:55:44 +0200
Subject: [Python-Dev] Proposed tweaks to functools.wraps
In-Reply-To: <AANLkTikZ75Vup=gZMuhL0AcB68QwOheJ3YypH-ZCeLtk@mail.gmail.com>
References: <AANLkTimQhkeUWHBLrsmW+JDOMimgjnpxihUh1L894Zoz@mail.gmail.com>
	<AANLkTikzBmQcdiLP+oDzeCd9jO4bzuN7msjs9=MfmTXb@mail.gmail.com>
	<AANLkTikxoNKPrV3HbPtV2Hxa9Z5sE++443CsmvZ8_jJw@mail.gmail.com>
	<201008112300.30677.steve@pearwood.info>
	<AANLkTim=oLuHYQ_7gjJE5LFc4LnJ0HhCTHP63Vy+BzDW@mail.gmail.com>
	<AANLkTikZ75Vup=gZMuhL0AcB68QwOheJ3YypH-ZCeLtk@mail.gmail.com>
Message-ID: <AANLkTimDrXFoHXU8txgcvRvYVnSZgyO80jTtBK7oR8py@mail.gmail.com>

On Wed, Aug 11, 2010 at 11:21 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> However, as I noted before, these kinds of scenario are the reason we
> decided that building this feature directly into the decorator
> machinery wasn't a good idea.

I agree. I was just replying to Steven's response to my post. :)

Schiavo
Simon

From raymond.hettinger at gmail.com  Thu Aug 12 00:01:34 2010
From: raymond.hettinger at gmail.com (Raymond Hettinger)
Date: Wed, 11 Aug 2010 15:01:34 -0700
Subject: [Python-Dev] Proposed tweaks to functools.wraps
In-Reply-To: <i3v56k$nok$1@dough.gmane.org>
References: <AANLkTimQhkeUWHBLrsmW+JDOMimgjnpxihUh1L894Zoz@mail.gmail.com>	<AANLkTikzBmQcdiLP+oDzeCd9jO4bzuN7msjs9=MfmTXb@mail.gmail.com>	<AANLkTikxoNKPrV3HbPtV2Hxa9Z5sE++443CsmvZ8_jJw@mail.gmail.com>	<201008112300.30677.steve@pearwood.info>
	<5618FDEE-F2BB-488C-8FBB-84CB2A48E39E@gmail.com>
	<i3v56k$nok$1@dough.gmane.org>
Message-ID: <3145C95F-4D18-4854-8201-7FE72657ECDA@gmail.com>


On Aug 11, 2010, at 2:37 PM, Terry Reedy wrote:

> On 8/11/2010 3:16 PM, Raymond Hettinger wrote:
> 
>> The ability to introspect is basic to Python's design.
>> Objects know their class, functions know their code objects,
>> bound methods know both their underlying function,
>> classes know their own class dictionary, etc.
> 
> Should iterators know their iterable when there is one?
> 
> There is or was a request for this on python-list, I believe, a few days ago. I suggested bad idea because
> a) iterator requirement is intentially minimal
> b) not all iterators have underlying object
> c) OP wanted to mutate underlying object (list) while iterating
> I did give a my_iter class that would do what OP wanted.

I agree with your assessment.
Also an iterator is a protocol, not a single class.


Raymond

From benjamin at python.org  Thu Aug 12 00:28:58 2010
From: benjamin at python.org (Benjamin Peterson)
Date: Wed, 11 Aug 2010 17:28:58 -0500
Subject: [Python-Dev] Proposed tweaks to functools.wraps
In-Reply-To: <3145C95F-4D18-4854-8201-7FE72657ECDA@gmail.com>
References: <AANLkTimQhkeUWHBLrsmW+JDOMimgjnpxihUh1L894Zoz@mail.gmail.com>
	<AANLkTikzBmQcdiLP+oDzeCd9jO4bzuN7msjs9=MfmTXb@mail.gmail.com>
	<AANLkTikxoNKPrV3HbPtV2Hxa9Z5sE++443CsmvZ8_jJw@mail.gmail.com>
	<201008112300.30677.steve@pearwood.info>
	<5618FDEE-F2BB-488C-8FBB-84CB2A48E39E@gmail.com>
	<i3v56k$nok$1@dough.gmane.org>
	<3145C95F-4D18-4854-8201-7FE72657ECDA@gmail.com>
Message-ID: <AANLkTi=cxaEg=+-tYsAQawPXsn=YRbmTxcvmpp94X9n2@mail.gmail.com>

2010/8/11 Raymond Hettinger <raymond.hettinger at gmail.com>:
>
> On Aug 11, 2010, at 2:37 PM, Terry Reedy wrote:
>
>> On 8/11/2010 3:16 PM, Raymond Hettinger wrote:
>>
>>> The ability to introspect is basic to Python's design.
>>> Objects know their class, functions know their code objects,
>>> bound methods know both their underlying function,
>>> classes know their own class dictionary, etc.
>>
>> Should iterators know their iterable when there is one?
>>
>> There is or was a request for this on python-list, I believe, a few days ago. I suggested bad idea because
>> a) iterator requirement is intentially minimal
>> b) not all iterators have underlying object
>> c) OP wanted to mutate underlying object (list) while iterating
>> I did give a my_iter class that would do what OP wanted.
>
> I agree with your assessment.
> Also an iterator is a protocol, not a single class.

As is decoration...



-- 
Regards,
Benjamin

From adal.chiriliuc at gmail.com  Thu Aug 12 01:11:27 2010
From: adal.chiriliuc at gmail.com (Adal Chiriliuc)
Date: Thu, 12 Aug 2010 02:11:27 +0300
Subject: [Python-Dev] Fixing #7175: a standard location for Python
	config files
Message-ID: <AANLkTikKbRXL=xnHXRYiyJ1fVBHF9Cx495hOuSrgvwv9@mail.gmail.com>

Hello,

Fred Drake fdrake at acm.org wrote:
> +0.5
>
> I'd like to see a more complete proposal, including:
>
> - what to do with Windows, Mac OS X

PEP 370 already specifies a directory for Python config files:

> user data directory
>
>     Usually the parent directory of the user site directory. It's meant for Python version specific data like config files, docs, > images and translations.
>
>     Unix (including Mac)
>         ~/.local/lib/python2.6
>     Windows
>         %APPDATA%/Python/Python26

Regards

From terrence at zettabytestorage.com  Thu Aug 12 00:58:46 2010
From: terrence at zettabytestorage.com (Terrence Cole)
Date: Wed, 11 Aug 2010 15:58:46 -0700
Subject: [Python-Dev] Proposed tweaks to functools.wraps
In-Reply-To: <AANLkTim6z1K3YMKT8aPVuaiPVbV_K=gua+_FNOYJCqsB@mail.gmail.com>
References: <AANLkTimQhkeUWHBLrsmW+JDOMimgjnpxihUh1L894Zoz@mail.gmail.com>
	<AANLkTikzBmQcdiLP+oDzeCd9jO4bzuN7msjs9=MfmTXb@mail.gmail.com>
	<AANLkTim6z1K3YMKT8aPVuaiPVbV_K=gua+_FNOYJCqsB@mail.gmail.com>
Message-ID: <1281567526.11315.13.camel@localhost>

On Wed, 2010-08-11 at 13:10 +1000, Nick Coghlan wrote:
> On Wed, Aug 11, 2010 at 12:39 PM, Benjamin Peterson <benjamin at python.org> wrote:
> > which would require ignoring the absence of __annotations__.
> 
> It turns out the patch that added __annotations__ support also made a
> change to make all of the copied attributes optional.

The discussion happened on issue 8814.  I initially made only
__annotations__ optional, however, after finding issue 1576241 on the
tracker and thinking about it a bit, making all of the annotations
optional seemed like the only sane solution.

http://bugs.python.org/issue8814
http://bugs.python.org/issue1576241

> So I'll be tidying up the implementation of that, extending it to the
> updated attributes and adding unit tests to make sure they're all
> optional.
> 
> Cheers,
> Nick.
> 
--
Terrence


From raymond.hettinger at gmail.com  Thu Aug 12 01:27:26 2010
From: raymond.hettinger at gmail.com (Raymond Hettinger)
Date: Wed, 11 Aug 2010 16:27:26 -0700
Subject: [Python-Dev] Proposed tweaks to functools.wraps
In-Reply-To: <AANLkTi=cxaEg=+-tYsAQawPXsn=YRbmTxcvmpp94X9n2@mail.gmail.com>
References: <AANLkTimQhkeUWHBLrsmW+JDOMimgjnpxihUh1L894Zoz@mail.gmail.com>
	<AANLkTikzBmQcdiLP+oDzeCd9jO4bzuN7msjs9=MfmTXb@mail.gmail.com>
	<AANLkTikxoNKPrV3HbPtV2Hxa9Z5sE++443CsmvZ8_jJw@mail.gmail.com>
	<201008112300.30677.steve@pearwood.info>
	<5618FDEE-F2BB-488C-8FBB-84CB2A48E39E@gmail.com>
	<i3v56k$nok$1@dough.gmane.org>
	<3145C95F-4D18-4854-8201-7FE72657ECDA@gmail.com>
	<AANLkTi=cxaEg=+-tYsAQawPXsn=YRbmTxcvmpp94X9n2@mail.gmail.com>
Message-ID: <478A2565-84A3-47BD-BE11-1F2D4AAD1C87@gmail.com>


On Aug 11, 2010, at 3:28 PM, Benjamin Peterson wrote:

> 2010/8/11 Raymond Hettinger <raymond.hettinger at gmail.com>:
>> 
>> On Aug 11, 2010, at 2:37 PM, Terry Reedy wrote:
>> 
>>> On 8/11/2010 3:16 PM, Raymond Hettinger wrote:
>>> 
>>>> The ability to introspect is basic to Python's design.
>>>> Objects know their class, functions know their code objects,
>>>> bound methods know both their underlying function,
>>>> classes know their own class dictionary, etc.
>>> 
>>> Should iterators know their iterable when there is one?
>>> 
>>> There is or was a request for this on python-list, I believe, a few days ago. I suggested bad idea because
>>> a) iterator requirement is intentially minimal
>>> b) not all iterators have underlying object
>>> c) OP wanted to mutate underlying object (list) while iterating
>>> I did give a my_iter class that would do what OP wanted.
>> 
>> I agree with your assessment.
>> Also an iterator is a protocol, not a single class.
> 
> As is decoration...

This isn't proposed for decoration in general,
just for wraps().  In that respect, it is very much
like bound methods or other things that introspect.

The length of the this thread is surprising.
It is a rather basic piece of functionality
with no real downside.


Raymond



From steve at holdenweb.com  Thu Aug 12 02:00:35 2010
From: steve at holdenweb.com (Steve Holden)
Date: Wed, 11 Aug 2010 20:00:35 -0400
Subject: [Python-Dev] Proposed tweaks to functools.wraps
In-Reply-To: <i3v56k$nok$1@dough.gmane.org>
References: <AANLkTimQhkeUWHBLrsmW+JDOMimgjnpxihUh1L894Zoz@mail.gmail.com>	<AANLkTikzBmQcdiLP+oDzeCd9jO4bzuN7msjs9=MfmTXb@mail.gmail.com>	<AANLkTikxoNKPrV3HbPtV2Hxa9Z5sE++443CsmvZ8_jJw@mail.gmail.com>	<201008112300.30677.steve@pearwood.info>	<5618FDEE-F2BB-488C-8FBB-84CB2A48E39E@gmail.com>
	<i3v56k$nok$1@dough.gmane.org>
Message-ID: <4C6339A3.7010407@holdenweb.com>

On 8/11/2010 5:37 PM, Terry Reedy wrote:
> On 8/11/2010 3:16 PM, Raymond Hettinger wrote:
> 
>> The ability to introspect is basic to Python's design.
>> Objects know their class, functions know their code objects,
>> bound methods know both their underlying function,
>> classes know their own class dictionary, etc.
> 
> Should iterators know their iterable when there is one?
> 
> There is or was a request for this on python-list, I believe, a few days
> ago. I suggested bad idea because
> a) iterator requirement is intentially minimal
> b) not all iterators have underlying object
> c) OP wanted to mutate underlying object (list) while iterating
> I did give a my_iter class that would do what OP wanted.
> 
Mutation of the underlying iterable is a terrible idea. Imagine the
confusion when multiple iterators are active on the same iterable. But I
suspect I am preaching to the choir here.

regards
 Steve
-- 
Steve Holden           +1 571 484 6266   +1 800 494 3119
DjangoCon US September 7-9, 2010    http://djangocon.us/
See Python Video!       http://python.mirocommunity.org/
Holden Web LLC                 http://www.holdenweb.com/


From merwok at netwok.org  Thu Aug 12 04:56:02 2010
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Thu, 12 Aug 2010 04:56:02 +0200
Subject: [Python-Dev] Fixing #7175: a standard location for Python
 config files
In-Reply-To: <AANLkTimk4Ei85NULF5HYyz=cvuzB6xP6JiAF63+6Z5so@mail.gmail.com>
References: <4C62C01D.6000900@netwok.org>
	<AANLkTimk4Ei85NULF5HYyz=cvuzB6xP6JiAF63+6Z5so@mail.gmail.com>
Message-ID: <4C6362C2.30004@netwok.org>

> I'd like to see a more complete proposal, including:
Fair enough.

tl;dr: Locating config files is hard.

I have looked at http://github.com/ActiveState/appdirs (MIT) for
OS-specific bits of knowledge. (Note that the directories it uses for
free OSes are not compliant with the freedesktop.org Base Directory
specification, which already did the reflexion and code to separate
config, user data and cache.)

> - what to do with Windows,
appdirs uses pywin32 or ctypes or _winreg to find the correct value for
the user settings directory. There is a new complication in recent
Windows called roaming profiles, which are copied from a server to
multiple clients and need synchronization calls.

> Mac OS X
There is debate between Ned Deily, Ronald Oussoren and Glyph Lefkowitz
as to whether Mac OS is just a Unix or a special beast. appdirs chooses
the Mac-specific directory. There are also probably variations between
system installations, framework things and unix-style installations.

> - backward compatibility considered
>   (seems straightforward, but seemings are often wrong)
Are you talking about finding config from older locations, or automatic
renaming of ~/.idlerc to ~/.python/idlerc? The former seems easy; not
sure how to do the latter. Gajim, a PyGTK Jabber client, moved from a
custom layout to BaseDir-compliant directories a few months ago; I think
it looks for the old directories on every startup to see if they need to
be moved. I?m not sure if this affects startup time noticeably, since
it?s after all a graphical network Python app, but it may be a concern
with programs that are run a lot like the unittest2 script (or not,
considering startup time of the interpreter).

> - cross-platform API to locate these files
I was thinking about adding a function to site with this tentative
signature:

def getuserconfig(appname=''):
    """Return the configuration file name for `appname`.

    If `appname` is the empty string, return the directory used for
    Python configuration files, else returns the file name used for the
    configuration file of `appname` (a PyPI project name).

    Strings starting with a number ('3.2') are reserved by Python.
    """

I?m not sure the x.y subdirectory is necessary. distutils config files
are compatible since forever and will still be compatible with
distutils2; config files in unittest2 are very recent, they could have a
policy of compatiblity too; I can investigate IDLE config format.

A boolean could control whether to return filenames using the old
conventions. On Windows, this would need application name and
author/vendor name (settings are grouped by author). On Mac, the
application would have to say whether it uses a unix-style dotfile or a
Mac-style directory. Also, capitalization differs across OSes. Can of
worms here.

> Seems like a good idea to have a "registry" of files known to be placed there
The project name registration on PyPI may be enough to avoid duplicates.


Next steps:

1) Find out if winreg is reliable enough, since we don?t want to depend
on ctypes or pywin32 IIRC.

2) Have the Mac people come to an agreement for each type of install.

3) Prototype the new function. It?s probably a good idea to contact the
author of appdirs and work with him on a Python-specific subset of his
module instead of rewriting the same code.

4) Think about the best way to handle b/w compat. Timings could help
deciding for or against automatic renaming.


Thanks for the feedback.


From merwok at netwok.org  Thu Aug 12 04:58:23 2010
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Thu, 12 Aug 2010 04:58:23 +0200
Subject: [Python-Dev] Fixing #7175: a standard location for Python
 config files
In-Reply-To: <AANLkTikKbRXL=xnHXRYiyJ1fVBHF9Cx495hOuSrgvwv9@mail.gmail.com>
References: <AANLkTikKbRXL=xnHXRYiyJ1fVBHF9Cx495hOuSrgvwv9@mail.gmail.com>
Message-ID: <4C63634F.4040401@netwok.org>

> PEP 370 already specifies a directory for Python config files:
> 
>> user data directory
>>
>>     Usually the parent directory of the user site directory.
>>     It's meant for Python version specific data like config
>>     files, docs, images and translations.

Thanks for pointing that. However, I have to disagree with the PEP here:
config files are not data files. Considering the FHS or the XDG Base
Directory specifications, there is a precedent in distinguishing user
config (edited by the user through a text editor or settings graphical
window), program data (state) and cache (files for speedups that can
safely be deleted).

Regards


From fdrake at acm.org  Thu Aug 12 05:10:20 2010
From: fdrake at acm.org (Fred Drake)
Date: Wed, 11 Aug 2010 23:10:20 -0400
Subject: [Python-Dev] Fixing #7175: a standard location for Python
	config files
In-Reply-To: <4C63634F.4040401@netwok.org>
References: <AANLkTikKbRXL=xnHXRYiyJ1fVBHF9Cx495hOuSrgvwv9@mail.gmail.com> 
	<4C63634F.4040401@netwok.org>
Message-ID: <AANLkTi=utfPzebnJnNag1C1sDOw9XNBEcaQ--Auwku7b@mail.gmail.com>

On Wed, Aug 11, 2010 at 10:58 PM, ?ric Araujo <merwok at netwok.org> wrote:
> Considering the FHS or the XDG Base
> Directory specifications, there is a precedent in distinguishing user
> config (edited by the user through a text editor or settings graphical
> window), program data (state) and cache (files for speedups that can
> safely be deleted).

Right.  The wording in that PEP is ambiguous at best, but the
inclusion of the Python version number in the listed path suggests
that this is for automatically managed stat (like those trashy *.pth
files some tools worry about), not for something the human user is
going to manipulate directly.

That PEP is particularly concerned with package management per user (a
dodgy proposition at best), so everything there is about package
management tool support, not user-manipulated configuration data.


? -Fred

--
Fred L. Drake, Jr.? ? <fdrake at gmail.com>
"A storm broke loose in my mind."? --Albert Einstein

From rowen at uw.edu  Thu Aug 12 07:00:41 2010
From: rowen at uw.edu (Russell E. Owen)
Date: Wed, 11 Aug 2010 22:00:41 -0700
Subject: [Python-Dev] Fixing #7175: a standard location for Python
	config files
References: <4C62C01D.6000900@netwok.org>
Message-ID: <rowen-7F4859.22004011082010@news.gmane.org>

In article <4C62C01D.6000900 at netwok.org>,
 ??ric Araujo <merwok at netwok.org> wrote:

> Hello list
> 
> Tarek opened a distutils bugs in http://bugs.python.org/issue7175 that
> evolved into a discussion about the proper location to use for config files.
> 
> Distutils uses [.]pydistutils.cfg and .pypirc, and now unittest2 has a
> config file too.
> 
> It would be nice to define one standard location for config files used
> by stdlib modules, and maybe also by third-party programs related
> closely to Python development (testing tools, static code checkers and
> the like), in a way that doesn???t clutter the user home directory with a
> dozen dotfiles while still being easily found.
> 
> (The Unix notions of dotfiles and home directory have to be adapted to
> use non-dotfiles in some standard place on various Windows. The Mac
> experts disagree on the right directory to use.)
> 
> Tarek, Antoine, RDM, MAL were +1 on using ~/.python (whether to use
> .pythonx.y or .python/x.y is a subissue to discuss after general agreement).
> 
> What do you think about this?

I like the idea as long as different versions of python have different 
directories and the files are intended to be user-specific.

If the files are shared among all users then /usr/local/<something> 
seems more reasonable.

I also think whatever you choose for linux is also the best choice for 
Mac OS X (my preferred platform). While there are other possible 
directories, such as ~/Library/Application Support/<something>, all 
tools derived from unix that I know about use the unix convention (ssh, 
X11, bash...) and I would argue that Python is close enough to count 
even though it is a framework build. Put another way, copying the unix 
convention is simple, is exactly what power users would expect and I 
don't see it would do any harm.

-- Russell


From ziade.tarek at gmail.com  Thu Aug 12 09:26:31 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 12 Aug 2010 09:26:31 +0200
Subject: [Python-Dev] Fixing #7175: a standard location for Python
	config files
In-Reply-To: <rowen-7F4859.22004011082010@news.gmane.org>
References: <4C62C01D.6000900@netwok.org>
	<rowen-7F4859.22004011082010@news.gmane.org>
Message-ID: <AANLkTinw4MhvH-ZU+H-F49LJMHwTrFmsxBHa5JescM24@mail.gmail.com>

On Thu, Aug 12, 2010 at 7:00 AM, Russell E. Owen <rowen at uw.edu> wrote:
...
>
> If the files are shared among all users then /usr/local/<something>
> seems more reasonable.
>
> I also think whatever you choose for linux is also the best choice for
> Mac OS X (my preferred platform). While there are other possible
> directories, such as ~/Library/Application Support/<something>, all
> tools derived from unix that I know about use the unix convention (ssh,
> X11, bash...) and I would argue that Python is close enough to count
> even though it is a framework build. Put another way, copying the unix
> convention is simple, is exactly what power users would expect and I
> don't see it would do any harm.

Choosing an arbitrary location we think is good on every system is fine
and non risky I think, as long as Python let the various distribution
change those paths though configuration.

In fact, that's one of the future goal of the sysconfig module I had in mind.

Instead of having it reading paths from python variables, I would like
to introduce
a configuration file global to Python containing all the installation paths, and
the paths we are currently discussing.

That file could then be changed by distributions depending on their layouts.

It will avoid distributions to hack Python to change those paths.
For instance, Ubuntu currently patches distutils to change the
installation paths.

So let's:

- define all the default locations for each system
- define a sysconfig.cfg file that contains all installation paths,
for each target system
- change sysconfig.py so it uses it, instead of the global dicts it
currently has


Regards
Tarek

-- 
Tarek Ziad? | http://ziade.org

From cournape at gmail.com  Thu Aug 12 10:38:52 2010
From: cournape at gmail.com (David Cournapeau)
Date: Thu, 12 Aug 2010 17:38:52 +0900
Subject: [Python-Dev] mingw support?
In-Reply-To: <40b838e9eeeac1852e96a0f5d25d67a0.squirrel@webmail.uio.no>
References: <20100807195541.GA13990@laptop.gs> <i3n225$osp$1@dough.gmane.org>
	<AANLkTi=dc=0brYo34=xaU6D9wH97eB_tTN=b=FBNjLNh@mail.gmail.com>
	<9f2ea5ad00140f45fdf639eb0b234aea.squirrel@webmail.uio.no>
	<i3q110$ncr$1@dough.gmane.org> <20100810140620.GB4464@laptop.gs>
	<AANLkTik0QoHNXGgqhbtQKJqrFoC3kxzzomm06sJfZLJ8@mail.gmail.com>
	<40b838e9eeeac1852e96a0f5d25d67a0.squirrel@webmail.uio.no>
Message-ID: <AANLkTimfAiHnLkq_6-uU=Xd-2+bZdHa8qn-4kLazbwS6@mail.gmail.com>

On Wed, Aug 11, 2010 at 10:21 PM, Sturla Molden <sturla at molden.no> wrote:
>
> "David Cournapeau":
>> Autotools only help for posix-like platforms. They are certainly a big
>> hindrance on windows platform in general,
>
> That is why mingw has MSYS.

I know of MSYS, but it is not very pleasant to use, if only because it
is extremely slow. When I need to build things for windows, I much
prefer cross compiling to using MSYS. I also think that cross
compilation is more useful than native mingw build alone - there are
patches for cross compilation, but I don't know their current status,

cheers,

David

From mail at timgolden.me.uk  Thu Aug 12 11:50:41 2010
From: mail at timgolden.me.uk (Tim Golden)
Date: Thu, 12 Aug 2010 10:50:41 +0100
Subject: [Python-Dev] Fixing #7175: a standard location for Python
 config files
In-Reply-To: <4C62C01D.6000900@netwok.org>
References: <4C62C01D.6000900@netwok.org>
Message-ID: <4C63C3F1.6000603@timgolden.me.uk>

On 11/08/2010 16:22, ?ric Araujo wrote:
> It would be nice to define one standard location for config files used
> by stdlib modules, and maybe also by third-party programs related
> closely to Python development (testing tools, static code checkers and
> the like), in a way that doesn?t clutter the user home directory with a
> dozen dotfiles while still being easily found.
>
> (The Unix notions of dotfiles and home directory have to be adapted to
> use non-dotfiles in some standard place on various Windows. The Mac
> experts disagree on the right directory to use.)

The canonical place on Windows (per Microsoft [1]) is:

for roaming data: the Application Data folder (exposed as the
APPDATA env var and as CSIDL_APPDATA pre-Vista and the
FOLDERID_RoamingAppData Known Folder on Vista+).

for non-roaming data: the local app data (CSIDL_LOCAL_APPDATA
or FOLDERID_LocalAppData)

The obvious difference is whether a user expects the data to be
available for the same account on a different computer. At present,
the user site packages are held under %APPDATA%\Python\Pythonxx,
ie are considered roaming.

Unfortunately, the canonical place is not always the place most
used. Especially since the convention under *nix is to place dotfile
or dotdirs under $HOME. Windows doesn't, by default, have a $HOME so
various locations are considered $HOME, including (but not limited
to):

* the directory pointed to by %HOME%
* the directory pointed to by %USERPROFILE%
* the "My Documents" shell folder
   (often, but not always, %USERPROFILE%\My Documents)
* c:\ (no: really)
* the NT profile home directory (typically a mapped share)

Dotfiles are possible on Windows; the issue is that they can't
be created within the shell (ie within Windows Explorer). They
can be renamed, edited, etc without issue, so it's not much of
a problem. They can be created by any program which can call
CreateFile -- including Python, obviously.

TJG

[1] http://support.microsoft.com/kb/310294

From steve at holdenweb.com  Thu Aug 12 12:18:27 2010
From: steve at holdenweb.com (Steve Holden)
Date: Thu, 12 Aug 2010 06:18:27 -0400
Subject: [Python-Dev] Fixing #7175: a standard location for Python
	config files
In-Reply-To: <4C63C3F1.6000603@timgolden.me.uk>
References: <4C62C01D.6000900@netwok.org> <4C63C3F1.6000603@timgolden.me.uk>
Message-ID: <i40hps$5r7$1@dough.gmane.org>

On 8/12/2010 5:50 AM, Tim Golden wrote:
> On 11/08/2010 16:22, ?ric Araujo wrote:
>> It would be nice to define one standard location for config files used
>> by stdlib modules, and maybe also by third-party programs related
>> closely to Python development (testing tools, static code checkers and
>> the like), in a way that doesn?t clutter the user home directory with a
>> dozen dotfiles while still being easily found.
>>
>> (The Unix notions of dotfiles and home directory have to be adapted to
>> use non-dotfiles in some standard place on various Windows. The Mac
>> experts disagree on the right directory to use.)
> 
> The canonical place on Windows (per Microsoft [1]) is:
> 
> for roaming data: the Application Data folder (exposed as the
> APPDATA env var and as CSIDL_APPDATA pre-Vista and the
> FOLDERID_RoamingAppData Known Folder on Vista+).
> 
> for non-roaming data: the local app data (CSIDL_LOCAL_APPDATA
> or FOLDERID_LocalAppData)
> 
> The obvious difference is whether a user expects the data to be
> available for the same account on a different computer. At present,
> the user site packages are held under %APPDATA%\Python\Pythonxx,
> ie are considered roaming.
> 
> Unfortunately, the canonical place is not always the place most
> used. Especially since the convention under *nix is to place dotfile
> or dotdirs under $HOME. Windows doesn't, by default, have a $HOME so
> various locations are considered $HOME, including (but not limited
> to):
> 
> * the directory pointed to by %HOME%
> * the directory pointed to by %USERPROFILE%
> * the "My Documents" shell folder
>   (often, but not always, %USERPROFILE%\My Documents)
> * c:\ (no: really)
> * the NT profile home directory (typically a mapped share)
> 
> Dotfiles are possible on Windows; the issue is that they can't
> be created within the shell (ie within Windows Explorer). They
> can be renamed, edited, etc without issue, so it's not much of
> a problem. They can be created by any program which can call
> CreateFile -- including Python, obviously.
> 
> TJG
> 
> [1] http://support.microsoft.com/kb/310294

Didn't we have this discussion when per-user libraries came up?
Shouldn't we be using a subdirectory of that location? We ruin the risk
of Python becoming distributed so finely it becomes impossible to change
things, what with per-user libraries, per-version shared binaries,
per-user-per-version library configuration files and the rest.

One might make a case that all configuration data should be stored in a
single SQLite database (with a suitable API to hide the relational
nature of the store). Then at least there would only be one file no
matter how many versions of Python were installed. Seriously. We are
already spending enough time doing stat calls on non-existent directories.

regards
 Steve

PS: Then we can start putting the libraries themselves in the database.
That works really well.
-- 
Steve Holden           +1 571 484 6266   +1 800 494 3119
DjangoCon US September 7-9, 2010    http://djangocon.us/
See Python Video!       http://python.mirocommunity.org/
Holden Web LLC                 http://www.holdenweb.com/


From mail at timgolden.me.uk  Thu Aug 12 12:30:14 2010
From: mail at timgolden.me.uk (Tim Golden)
Date: Thu, 12 Aug 2010 11:30:14 +0100
Subject: [Python-Dev] Fixing #7175: a standard location for
 Python	config files
In-Reply-To: <i40hps$5r7$1@dough.gmane.org>
References: <4C62C01D.6000900@netwok.org> <4C63C3F1.6000603@timgolden.me.uk>
	<i40hps$5r7$1@dough.gmane.org>
Message-ID: <4C63CD36.4050400@timgolden.me.uk>

On 12/08/2010 11:18, Steve Holden wrote:
> On 8/12/2010 5:50 AM, Tim Golden wrote:

[... snip explanation of standard & non-standard locations ...]

> Didn't we have this discussion when per-user libraries came up?
> Shouldn't we be using a subdirectory of that location?

Yes we should. My explanation above was really just painting the
picture. It should have been an Appendix for the Truly Interested.

> One might make a case that all configuration data should be stored in a
> single SQLite database (with a suitable API to hide the relational
> nature of the store). Then at least there would only be one file no
> matter how many versions of Python were installed. Seriously. We are
> already spending enough time doing stat calls on non-existent directories.

-1 on this. I don't care how many stats we're doing; I want to be able
to see my configuration / libraries etc without firing up a sqlite
session.

TJG

From mail at timgolden.me.uk  Thu Aug 12 12:33:59 2010
From: mail at timgolden.me.uk (Tim Golden)
Date: Thu, 12 Aug 2010 11:33:59 +0100
Subject: [Python-Dev] Fixing #7175: a standard location for Python
 config files
In-Reply-To: <4C63C3F1.6000603@timgolden.me.uk>
References: <4C62C01D.6000900@netwok.org> <4C63C3F1.6000603@timgolden.me.uk>
Message-ID: <4C63CE17.4040804@timgolden.me.uk>

On 12/08/2010 10:50, Tim Golden wrote:
> Unfortunately, the canonical place is not always the place most
> used. Especially since the convention under *nix is to place dotfile
> or dotdirs under $HOME. Windows doesn't, by default, have a $HOME so
> various locations are considered $HOME, including (but not limited
> to):
>
> * the directory pointed to by %HOME%
> * the directory pointed to by %USERPROFILE%
> * the "My Documents" shell folder
> (often, but not always, %USERPROFILE%\My Documents)
> * c:\ (no: really)
> * the NT profile home directory (typically a mapped share)

Additionally, on Windows Python expands ~ to the first of:

%HOME%
%USERPROFILE%
%HOMEDRIVE%\%HOMEPATH%

all of which are perfectly defensible defintions of "Home" on
Windows. But combining that with the Unix-minded concept of
"create a dotfile called ~/.myapp" means you get dotapps in
non-standard places on Windows.

TJG

From fuzzyman at voidspace.org.uk  Thu Aug 12 12:40:14 2010
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Thu, 12 Aug 2010 11:40:14 +0100
Subject: [Python-Dev] Fixing #7175: a standard location for
 Python	config files
In-Reply-To: <i40hps$5r7$1@dough.gmane.org>
References: <4C62C01D.6000900@netwok.org> <4C63C3F1.6000603@timgolden.me.uk>
	<i40hps$5r7$1@dough.gmane.org>
Message-ID: <4C63CF8E.1090308@voidspace.org.uk>

On 12/08/2010 11:18, Steve Holden wrote:
> On 8/12/2010 5:50 AM, Tim Golden wrote:
>    
>> On 11/08/2010 16:22, ?ric Araujo wrote:
>>      
>>> It would be nice to define one standard location for config files used
>>> by stdlib modules, and maybe also by third-party programs related
>>> closely to Python development (testing tools, static code checkers and
>>> the like), in a way that doesn?t clutter the user home directory with a
>>> dozen dotfiles while still being easily found.
>>>
>>> (The Unix notions of dotfiles and home directory have to be adapted to
>>> use non-dotfiles in some standard place on various Windows. The Mac
>>> experts disagree on the right directory to use.)
>>>        
>> The canonical place on Windows (per Microsoft [1]) is:
>>
>> for roaming data: the Application Data folder (exposed as the
>> APPDATA env var and as CSIDL_APPDATA pre-Vista and the
>> FOLDERID_RoamingAppData Known Folder on Vista+).
>>
>> for non-roaming data: the local app data (CSIDL_LOCAL_APPDATA
>> or FOLDERID_LocalAppData)
>>
>> The obvious difference is whether a user expects the data to be
>> available for the same account on a different computer. At present,
>> the user site packages are held under %APPDATA%\Python\Pythonxx,
>> ie are considered roaming.
>>
>> Unfortunately, the canonical place is not always the place most
>> used. Especially since the convention under *nix is to place dotfile
>> or dotdirs under $HOME. Windows doesn't, by default, have a $HOME so
>> various locations are considered $HOME, including (but not limited
>> to):
>>
>> * the directory pointed to by %HOME%
>> * the directory pointed to by %USERPROFILE%
>> * the "My Documents" shell folder
>>    (often, but not always, %USERPROFILE%\My Documents)
>> * c:\ (no: really)
>> * the NT profile home directory (typically a mapped share)
>>
>> Dotfiles are possible on Windows; the issue is that they can't
>> be created within the shell (ie within Windows Explorer). They
>> can be renamed, edited, etc without issue, so it's not much of
>> a problem. They can be created by any program which can call
>> CreateFile -- including Python, obviously.
>>
>> TJG
>>
>> [1] http://support.microsoft.com/kb/310294
>>      
> Didn't we have this discussion when per-user libraries came up?
> Shouldn't we be using a subdirectory of that location? We ruin the risk
> of Python becoming distributed so finely it becomes impossible to change
> things, what with per-user libraries, per-version shared binaries,
> per-user-per-version library configuration files and the rest.
>
>    

User editable configuration files are very different from libraries. The 
per user site-packages folder *should* be hidden somewhere out of the 
way where you can get at them if you want them but won't stumble across 
them all the time. e.g. AppData on Windows.

For files we expect the user to be able to edit we shouldn't go out of 
our way to make them hard or inconvenient to find.

> One might make a case that all configuration data should be stored in a
> single SQLite database (with a suitable API to hide the relational
> nature of the store).
Yay - let's recreate the Windows registry! A binary blob only editable 
with special tools, we know how much users love that.


Michael

>   Then at least there would only be one file no
> matter how many versions of Python were installed. Seriously. We are
> already spending enough time doing stat calls on non-existent directories.
>
> regards
>   Steve
>
> PS: Then we can start putting the libraries themselves in the database.
> That works really well.
>    


-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (?BOGUS AGREEMENTS?) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.



From mail at timgolden.me.uk  Thu Aug 12 12:54:29 2010
From: mail at timgolden.me.uk (Tim Golden)
Date: Thu, 12 Aug 2010 11:54:29 +0100
Subject: [Python-Dev] Fixing #7175: a standard location for
 Python	config files
In-Reply-To: <4C63CF8E.1090308@voidspace.org.uk>
References: <4C62C01D.6000900@netwok.org>
	<4C63C3F1.6000603@timgolden.me.uk>	<i40hps$5r7$1@dough.gmane.org>
	<4C63CF8E.1090308@voidspace.org.uk>
Message-ID: <4C63D2E5.80606@timgolden.me.uk>

On 12/08/2010 11:40, Michael Foord wrote:
> User editable configuration files are very different from libraries. The
> per user site-packages folder *should* be hidden somewhere out of the
> way where you can get at them if you want them but won't stumble across
> them all the time. e.g. AppData on Windows.
>
> For files we expect the user to be able to edit we shouldn't go out of
> our way to make them hard or inconvenient to find.

This really comes down -- as with the Mac discussion last week, I
think -- to the tension between standard file locations and easy-to-get-to.
The difference on Windows, though, is that while on Mac it's either:
Apple standard /This/That/TheOther vs Unix standard $HOME/.something
on Windows it's %APPDATA%\myprog vs whatever-I-thought-of-at-the-time.

APPDATA isn't actually that hard to get to on any version of Windows
post 2000. (Just stick %APPDATA% into any Explorer window -- even
IE, for goodness sake). Even from the command line it's not hard:

notepad "%APPDATA%\python\python26\idle.ini"

Ultimately, as a Windows user/developer, I'd vote for a memorable
consistency, which for me would be %APPDATA%\python\... If everything's
in one place, I'll just create a shortcut / hardlink / whatever to get
me there when I want to change things.

TJG

From fuzzyman at voidspace.org.uk  Thu Aug 12 13:17:49 2010
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Thu, 12 Aug 2010 12:17:49 +0100
Subject: [Python-Dev] Fixing #7175: a standard location for
 Python	config files
In-Reply-To: <4C63D2E5.80606@timgolden.me.uk>
References: <4C62C01D.6000900@netwok.org>	<4C63C3F1.6000603@timgolden.me.uk>	<i40hps$5r7$1@dough.gmane.org>	<4C63CF8E.1090308@voidspace.org.uk>
	<4C63D2E5.80606@timgolden.me.uk>
Message-ID: <4C63D85D.1020409@voidspace.org.uk>

On 12/08/2010 11:54, Tim Golden wrote:
> On 12/08/2010 11:40, Michael Foord wrote:
>> User editable configuration files are very different from libraries. The
>> per user site-packages folder *should* be hidden somewhere out of the
>> way where you can get at them if you want them but won't stumble across
>> them all the time. e.g. AppData on Windows.
>>
>> For files we expect the user to be able to edit we shouldn't go out of
>> our way to make them hard or inconvenient to find.
>
> This really comes down -- as with the Mac discussion last week, I
> think -- to the tension between standard file locations and 
> easy-to-get-to.
> The difference on Windows, though, is that while on Mac it's either:
> Apple standard /This/That/TheOther vs Unix standard $HOME/.something
> on Windows it's %APPDATA%\myprog vs whatever-I-thought-of-at-the-time.
>
> APPDATA isn't actually that hard to get to on any version of Windows
> post 2000. (Just stick %APPDATA% into any Explorer window -- even
> IE, for goodness sake). Even from the command line it's not hard:
>
> notepad "%APPDATA%\python\python26\idle.ini"
>
> Ultimately, as a Windows user/developer, I'd vote for a memorable
> consistency, which for me would be %APPDATA%\python\... If everything's
> in one place, I'll just create a shortcut / hardlink / whatever to get
> me there when I want to change things.


How is ~/python not memorable or consistent? (And cross-platform 
memorability and consistency is valuable too.)

Another issue is discoverability. Many users won't know about these 
config files unless they *see* them. Sure if you *know* where they are 
then editing them is easy - but how often as a user do you browse your 
AppData folder? (As a windows user the only times I went delving in this 
mysterious location was trying to diagnose obscure errors.)

I'm not aware of any consistent pattern of putting *user editable* files 
in AppData, and I doubt this is where most users would look for them. In 
fact for Windows the *correct* thing to do is probably to use the 
registry and then provide a graphical tool for editing the values. If 
you're arguing for consistency why not argue for this? If we were to 
provide native GUI tools for editing values then the location suggested 
by Ronald for the Mac (which is the standard location for preferences 
files maintained by GUI tools) would also be the right location.

All the best,

Michael

>
> TJG
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at 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/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (?BOGUS AGREEMENTS?) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.



From solipsis at pitrou.net  Thu Aug 12 13:56:39 2010
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Thu, 12 Aug 2010 13:56:39 +0200
Subject: [Python-Dev] Remove "unit test needed"
Message-ID: <20100812135639.541ac252@pitrou.net>


Hello,

I would like to see ?unit test needed? removed from the workflow menu in
the bug tracker. The reason is that we don't do test-driven development
(or, at least, most of us don't) and this stage entry is therefore
useless and confusing. Saying to someone that an unit test is needed
happens during the patch review - it isn't a separate stage in itself.

The reason I'm asking is that I've seen some triagers bumping a lot of
issues to ?unit test needed? lately, and I find this annoying. What we
need is patches, not unit tests per se.

Regards

Antoine.



From mail at timgolden.me.uk  Thu Aug 12 13:59:05 2010
From: mail at timgolden.me.uk (Tim Golden)
Date: Thu, 12 Aug 2010 12:59:05 +0100
Subject: [Python-Dev] Fixing #7175: a standard location for
 Python	config files
In-Reply-To: <4C63D85D.1020409@voidspace.org.uk>
References: <4C62C01D.6000900@netwok.org>	<4C63C3F1.6000603@timgolden.me.uk>	<i40hps$5r7$1@dough.gmane.org>	<4C63CF8E.1090308@voidspace.org.uk>
	<4C63D2E5.80606@timgolden.me.uk>
	<4C63D85D.1020409@voidspace.org.uk>
Message-ID: <4C63E209.6040103@timgolden.me.uk>

On 12/08/2010 12:17, Michael Foord wrote:
>
> How is ~/python not memorable or consistent? (And cross-platform
> memorability and consistency is valuable too.)

I was thinking outside Python rather than inside it (where ~ has no
meaning on Windows) but you make a good point here. If we were just
discussing Python code this would effectively be a winning point IMO.

> Another issue is discoverability. Many users won't know about these
> config files unless they *see* them.

While I sympathise with this, I'm not sure how much weight
one should give it in the context of this discussion. In the Unix
world, if I were guessing, I would justifiably look in
~/.myapp followed perhaps by /etc/myapp. On Windows, I might go
for the registry, as you mention elsewhere, and look in
HKLM\Software\MyApp but for actual files I'm not sure where
"discoverable" would be.

re: using the Registry: To be honest, I was answering the literal
question posed by Eric: where to put config files? Not the wider
question: how should config data be stored? Where the answer to
the latter question might be: the Registry -- much as I find it
awkward to work with at times.

One very definite point in its favour as regards this discussion
is that Python on Windows *already* defines a key in the Registry
(and has done so since v2.0 at least) and it would make some sense
to place things under there.

Ultimately, I don't feel very strongly about this subject. I'm more
concerned that the chosen location (file or registry or whatever) be
documented -- and documented from a Windows perspective as well, so
you don't have to guess what "HOME" means in this context.


TJG

From merwok at netwok.org  Thu Aug 12 14:24:03 2010
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Thu, 12 Aug 2010 14:24:03 +0200
Subject: [Python-Dev] Fixing #7175: a standard location for
 Python	config files
In-Reply-To: <AANLkTinw4MhvH-ZU+H-F49LJMHwTrFmsxBHa5JescM24@mail.gmail.com>
References: <4C62C01D.6000900@netwok.org>	<rowen-7F4859.22004011082010@news.gmane.org>
	<AANLkTinw4MhvH-ZU+H-F49LJMHwTrFmsxBHa5JescM24@mail.gmail.com>
Message-ID: <4C63E7E3.3090100@netwok.org>

>> If the files are shared among all users then /usr/local/<something>
>> seems more reasonable.

Oh, right, I forgot to think about system-wide config files. They have
to be supported by another function in site.

A lot of programs have similar-looking code to get a list of filenames
and then process it with configparser or something else:
find_config_files in Distutils, get_standard_config_files in Docutils,
rcpath in Mercurial. There are different namings to support (rc, .cfg,
.conf, etc.) and also config directories (for Mercurial), but it does
not seem impossible to define a standard function that would benefit
Python itself and other programs.

> Choosing an arbitrary location we think is good on every system is fine
> and non risky I think, as long as Python let the various distribution
> change those paths though configuration.

Don?t you have a bootstrapping problem? How do you know where to look at
the sysconfig file that tells where to look at config files?

> In fact, that's one of the future goal of the sysconfig module I had in mind.

Seems great.

> So let's:
> 
> - define all the default locations for each system
> - define a sysconfig.cfg file that contains all installation paths,
> for each target system
> - change sysconfig.py so it uses it, instead of the global dicts it
> currently has

I wonder if this is so complex that a wiki page or something else would
be better suited than email to iron out the proposal. Or maybe it?s time
for that sysconfig.cfg PEP you planned to do.

Regards


From merwok at netwok.org  Thu Aug 12 14:38:09 2010
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Thu, 12 Aug 2010 14:38:09 +0200
Subject: [Python-Dev] Fixing #7175: a standard location for Python
 config files
In-Reply-To: <i40hps$5r7$1@dough.gmane.org>
References: <4C62C01D.6000900@netwok.org> <4C63C3F1.6000603@timgolden.me.uk>
	<i40hps$5r7$1@dough.gmane.org>
Message-ID: <4C63EB31.5040403@netwok.org>

Le 12/08/2010 12:18, Steve Holden a ?crit :
> Didn't we have this discussion when per-user libraries came up?
> Shouldn't we be using a subdirectory of that location?

As pointed out by Antoine, Georg, Michael and I, the PEP 370 directory
for user site-packages is not the right place to put config files.

> PS: Then we can start putting the libraries themselves in the database.
> That works really well.

I don?t know you well enough to tell if this is the final hint that you
were sarcastic.

Regards


From p.f.moore at gmail.com  Thu Aug 12 14:39:07 2010
From: p.f.moore at gmail.com (Paul Moore)
Date: Thu, 12 Aug 2010 13:39:07 +0100
Subject: [Python-Dev] Fixing #7175: a standard location for Python
	config files
In-Reply-To: <4C63E209.6040103@timgolden.me.uk>
References: <4C62C01D.6000900@netwok.org> <4C63C3F1.6000603@timgolden.me.uk>
	<i40hps$5r7$1@dough.gmane.org> <4C63CF8E.1090308@voidspace.org.uk>
	<4C63D2E5.80606@timgolden.me.uk>
	<4C63D85D.1020409@voidspace.org.uk>
	<4C63E209.6040103@timgolden.me.uk>
Message-ID: <AANLkTikLAGzgSgY0m7VFJAvqM8iDgp2ZT37NVBcO7fbB@mail.gmail.com>

On 12 August 2010 12:59, Tim Golden <mail at timgolden.me.uk> wrote:
> re: using the Registry: To be honest, I was answering the literal
> question posed by Eric: where to put config files? Not the wider
> question: how should config data be stored? Where the answer to
> the latter question might be: the Registry -- much as I find it
> awkward to work with at times.
>
> One very definite point in its favour as regards this discussion
> is that Python on Windows *already* defines a key in the Registry
> (and has done so since v2.0 at least) and it would make some sense
> to place things under there.
>
> Ultimately, I don't feel very strongly about this subject. I'm more
> concerned that the chosen location (file or registry or whatever) be
> documented -- and documented from a Windows perspective as well, so
> you don't have to guess what "HOME" means in this context.

One potential solution would be to use something like
os.path.expanduser("~/.python"), where os.path.expanduser has a
defined behaviour on Windows (one that could do with a little
clarification, yes I know, doc patch welcomed...), but also add an
additional option, that os.path.expanduser will first look in the
registry for the value HKLM\Software\Python\PythonCore\HOME and use
that if present. Then users could set their own interpretation, in a
Windows-standard manner.

If that would be an acceptable option, I could supply a patch to
os.path.expanduser. I will do a clarifying doc patch regardless.

Paul.

PS We could also support ~user by looking in HKEY_USERS\<user
SID>\Software\Python\... but that's probably YAGNI :-)

From merwok at netwok.org  Thu Aug 12 14:41:34 2010
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Thu, 12 Aug 2010 14:41:34 +0200
Subject: [Python-Dev] Fixing #7175: a standard location for
 Python	config files
In-Reply-To: <4C63E209.6040103@timgolden.me.uk>
References: <4C62C01D.6000900@netwok.org>	<4C63C3F1.6000603@timgolden.me.uk>	<i40hps$5r7$1@dough.gmane.org>	<4C63CF8E.1090308@voidspace.org.uk>	<4C63D2E5.80606@timgolden.me.uk>	<4C63D85D.1020409@voidspace.org.uk>
	<4C63E209.6040103@timgolden.me.uk>
Message-ID: <4C63EBFE.70807@netwok.org>

> Ultimately, I don't feel very strongly about this subject. I'm more
> concerned that the chosen location (file or registry or whatever) be
> documented -- and documented from a Windows perspective as well, so
> you don't have to guess what "HOME" means in this context.

Rest assured that I don?t want to impose Unix concepts on Windows. My
examples have used dotfiles since it?s what I know, but I did search and
ask for the right thing to do on other platforms.

Regards


From fdrake at acm.org  Thu Aug 12 15:10:03 2010
From: fdrake at acm.org (Fred Drake)
Date: Thu, 12 Aug 2010 09:10:03 -0400
Subject: [Python-Dev] Fixing #7175: a standard location for Python
	config files
In-Reply-To: <i40hps$5r7$1@dough.gmane.org>
References: <4C62C01D.6000900@netwok.org> <4C63C3F1.6000603@timgolden.me.uk>
	<i40hps$5r7$1@dough.gmane.org>
Message-ID: <AANLkTim04GLfqfR0U8GzzzveKF9iWaGo7_vw9bvnz3Mk@mail.gmail.com>

On Thu, Aug 12, 2010 at 6:18 AM, Steve Holden <steve at holdenweb.com> wrote:
> Didn't we have this discussion when per-user libraries came up?
> Shouldn't we be using a subdirectory of that location? We ruin the risk
> of Python becoming distributed so finely it becomes impossible to change
> things, what with per-user libraries, per-version shared binaries,
> per-user-per-version library configuration files and the rest.

Yes, we did.  That was in the context of some people's desire for a
per-user site-packages directory, and the result is that we're now
saddled with a per-user site-packages directory.

The structure determined there was the same sort of half-way
version-specific mess as so many others are: libraries are
per-python-version, and scripts are installed cowboy-style (whoever
got there last, wins).

Perhaps user configuration belongs in ~/.local/, or ~/.local/python/
(with attendant Windows & Mac OS noises); I don't really care where it
lands, because right now we just have a mess.  Getting it "right" with
respect to Window's "roaming" notion and how people expect to work
with it is... unlikely.  Picking a place is better than not, so we
know where to find things.  But that's all it buys us.


? -Fred

--
Fred L. Drake, Jr.? ? <fdrake at gmail.com>
"A storm broke loose in my mind."? --Albert Einstein

From dickinsm at gmail.com  Thu Aug 12 15:18:31 2010
From: dickinsm at gmail.com (Mark Dickinson)
Date: Thu, 12 Aug 2010 14:18:31 +0100
Subject: [Python-Dev] Remove "unit test needed"
In-Reply-To: <20100812135639.541ac252@pitrou.net>
References: <20100812135639.541ac252@pitrou.net>
Message-ID: <AANLkTi=mst+SpNyi-Np96jqsc9zqFQLnkUEj0pdFUV0m@mail.gmail.com>

On Thu, Aug 12, 2010 at 12:56 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
>
> Hello,
>
> I would like to see ?unit test needed? removed from the workflow menu in
> the bug tracker. The reason is that we don't do test-driven development
> (or, at least, most of us don't) and this stage entry is therefore
> useless and confusing. Saying to someone that an unit test is needed
> happens during the patch review - it isn't a separate stage in itself.

Is that stage supposed to (at least partly) capture the idea
'reproducible test-case needed', or 'verification needed'?  That would
seem like a more useful notion.

Mark

From linux at gabriel-striewe.de  Thu Aug 12 17:00:11 2010
From: linux at gabriel-striewe.de (linux at gabriel-striewe.de)
Date: Thu, 12 Aug 2010 17:00:11 +0200
Subject: [Python-Dev] mingw support?
In-Reply-To: <AANLkTimfAiHnLkq_6-uU=Xd-2+bZdHa8qn-4kLazbwS6@mail.gmail.com>
References: <20100807195541.GA13990@laptop.gs> <i3n225$osp$1@dough.gmane.org>
	<AANLkTi=dc=0brYo34=xaU6D9wH97eB_tTN=b=FBNjLNh@mail.gmail.com>
	<9f2ea5ad00140f45fdf639eb0b234aea.squirrel@webmail.uio.no>
	<i3q110$ncr$1@dough.gmane.org> <20100810140620.GB4464@laptop.gs>
	<AANLkTik0QoHNXGgqhbtQKJqrFoC3kxzzomm06sJfZLJ8@mail.gmail.com>
	<40b838e9eeeac1852e96a0f5d25d67a0.squirrel@webmail.uio.no>
	<AANLkTimfAiHnLkq_6-uU=Xd-2+bZdHa8qn-4kLazbwS6@mail.gmail.com>
Message-ID: <20100812150011.GA11541@laptop.gs>

On Thu, Aug 12, 2010 at 05:38:52PM +0900, David Cournapeau wrote:
> On Wed, Aug 11, 2010 at 10:21 PM, Sturla Molden <sturla at molden.no> wrote:
> >
> > "David Cournapeau":
> >> Autotools only help for posix-like platforms. They are certainly a big
> >> hindrance on windows platform in general,
> >
> > That is why mingw has MSYS.
> 
> I know of MSYS, but it is not very pleasant to use, if only because it
> is extremely slow. When I need to build things for windows, I much
> prefer cross compiling to using MSYS. I also think that cross
> compilation is more useful than native mingw build alone - there are
> patches for cross compilation, but I don't know their current status,
> 
> cheers,
> 
> David

My argument goes that one of the biggest differences between the
GNU/Linux and the Windows way of computing is the barrier between user
and programmer. In the Windows way, you are either a user or a
programmer. On Linux, just by the way you can download software and
run ./configure &&  make && make install, you are encouraged to look at the
source code and by this you might in the not-so-long run start
reporting bugs to mailing lists and see that there are actually people
who might be able to sort out the bugs and that you might become one
of them.

The Windows way, you think those bugs are unavoidable and start making
jokes out of a feeling of frustration and helplessness.

That's where msys/mingw is supposed to come in, if only it was easier
to install, so that new Programmers don't get locked in in the
Microsoft compiler products and thereby the divide between the
software communities gets wider and wider. 

Don't get me wrong, I think the python project is doing a great job in
terms of cross-platform portability, but things would be easier if
there was an easy combination of msys, mingw and autotools.

And by the way, I think the way the big linux distros like fedora and
mandrake distribute software is more similar to the windows way of
computing. 

Gabriel 



From alexander.belopolsky at gmail.com  Thu Aug 12 17:02:29 2010
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Thu, 12 Aug 2010 11:02:29 -0400
Subject: [Python-Dev] Remove "unit test needed"
In-Reply-To: <AANLkTi=mst+SpNyi-Np96jqsc9zqFQLnkUEj0pdFUV0m@mail.gmail.com>
References: <20100812135639.541ac252@pitrou.net>
	<AANLkTi=mst+SpNyi-Np96jqsc9zqFQLnkUEj0pdFUV0m@mail.gmail.com>
Message-ID: <AANLkTimSc3RRBeQ6NBZcVxD4w_gF9jddyP47h3PEC_xU@mail.gmail.com>

On Thu, Aug 12, 2010 at 9:18 AM, Mark Dickinson <dickinsm at gmail.com> wrote:
> On Thu, Aug 12, 2010 at 12:56 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
..
>> I would like to see ?unit test needed? removed from the workflow menu in
>> the bug tracker.
..
> Is that stage supposed to (at least partly) capture the idea
> 'reproducible test-case needed', or 'verification needed'? ?That would
> seem like a more useful notion.
>
+1

I have two problems with  ?unit test needed?:

1.  Similar to Antoine, I find it ambiguous whether a bug without a
patch is in ?unit test needed? or "patch needed" stage.

2.  I much prefer a small script reproducing the bug to a regression
suite patch.  In most cases unit tests require too much irrelevant
scaffolding to be useful in understanding or debugging the issue.

I remember there was an idea somewhere to replace "patch" tag with a
check-list with boxes for code, tests, and docs.  I think that would
be better than "unit test needed" stage.

From cesare.di.mauro at gmail.com  Thu Aug 12 17:22:12 2010
From: cesare.di.mauro at gmail.com (Cesare Di Mauro)
Date: Thu, 12 Aug 2010 17:22:12 +0200
Subject: [Python-Dev] mingw support?
In-Reply-To: <20100812150011.GA11541@laptop.gs>
References: <20100807195541.GA13990@laptop.gs> <i3n225$osp$1@dough.gmane.org>
	<AANLkTi=dc=0brYo34=xaU6D9wH97eB_tTN=b=FBNjLNh@mail.gmail.com>
	<9f2ea5ad00140f45fdf639eb0b234aea.squirrel@webmail.uio.no>
	<i3q110$ncr$1@dough.gmane.org> <20100810140620.GB4464@laptop.gs>
	<AANLkTik0QoHNXGgqhbtQKJqrFoC3kxzzomm06sJfZLJ8@mail.gmail.com>
	<40b838e9eeeac1852e96a0f5d25d67a0.squirrel@webmail.uio.no>
	<AANLkTimfAiHnLkq_6-uU=Xd-2+bZdHa8qn-4kLazbwS6@mail.gmail.com>
	<20100812150011.GA11541@laptop.gs>
Message-ID: <AANLkTikaafnJJBgiYfJf+v1B21RizYSjEzMBKRkBdLVL@mail.gmail.com>

2010/8/12  <linux at gabriel-striewe.de>
>
> On Thu, Aug 12, 2010 at 05:38:52PM +0900, David Cournapeau wrote:
> > On Wed, Aug 11, 2010 at 10:21 PM, Sturla Molden <sturla at molden.no>
> wrote:
> > >
> > > "David Cournapeau":
> > >> Autotools only help for posix-like platforms. They are certainly a big
> > >> hindrance on windows platform in general,
> > >
> > > That is why mingw has MSYS.
> >
> > I know of MSYS, but it is not very pleasant to use, if only because it
> > is extremely slow. When I need to build things for windows, I much
> > prefer cross compiling to using MSYS. I also think that cross
> > compilation is more useful than native mingw build alone - there are
> > patches for cross compilation, but I don't know their current status,
> >
> > cheers,
> >
> > David
>
> My argument goes that one of the biggest differences between the
> GNU/Linux and the Windows way of computing is the barrier between user
> and programmer. In the Windows way, you are either a user or a
> programmer. On Linux, just by the way you can download software and
> run ./configure &&  make && make install, you are encouraged to look at the
> source code and by this you might in the not-so-long run start
> reporting bugs to mailing lists and see that there are actually people
> who might be able to sort out the bugs and that you might become one
> of them.
>
> The Windows way, you think those bugs are unavoidable and start making
> jokes out of a feeling of frustration and helplessness.
>
> That's where msys/mingw is supposed to come in, if only it was easier
> to install, so that new Programmers don't get locked in in the
> Microsoft compiler products and thereby the divide between the
> software communities gets wider and wider.
>
> Don't get me wrong, I think the python project is doing a great job in
> terms of cross-platform portability, but things would be easier if
> there was an easy combination of msys, mingw and autotools.
>
> And by the way, I think the way the big linux distros like fedora and
> mandrake distribute software is more similar to the windows way of
> computing.
>
> Gabriel
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/cesare.di.mauro%40gmail.com
>

Anyway Visual Studio, even with the Express Edition, is simpler and more
productive for a Windows programmer.

You must suggest at least an equivalent "free" alternative to make the
switch convenient.

Otherwise we are talking about philosophy or religion, and nobody will
change his ideas.

Cesare
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100812/4b574406/attachment.html>

From fdrake at acm.org  Thu Aug 12 19:31:38 2010
From: fdrake at acm.org (Fred Drake)
Date: Thu, 12 Aug 2010 13:31:38 -0400
Subject: [Python-Dev] Remove "unit test needed"
In-Reply-To: <AANLkTimSc3RRBeQ6NBZcVxD4w_gF9jddyP47h3PEC_xU@mail.gmail.com>
References: <20100812135639.541ac252@pitrou.net>
	<AANLkTi=mst+SpNyi-Np96jqsc9zqFQLnkUEj0pdFUV0m@mail.gmail.com>
	<AANLkTimSc3RRBeQ6NBZcVxD4w_gF9jddyP47h3PEC_xU@mail.gmail.com>
Message-ID: <AANLkTimkE+LSPT7Rm7-VQrd6nAzzkGc91=8YLg5qZhsX@mail.gmail.com>

On Thu, Aug 12, 2010 at 11:02 AM, Alexander Belopolsky
<alexander.belopolsky at gmail.com> wrote:
> I remember there was an idea somewhere to replace "patch" tag with a
> check-list with boxes for code, tests, and docs. ?I think that would
> be better than "unit test needed" stage.

Are you suggesting check boxes for what's needed, or for what's present?

Boxes indicating the needs would probably be most useful.  These
should probably all be set by default on new issues.

Using keywords would be acceptable, I think.  Similar to "needs review".


? -Fred

--
Fred L. Drake, Jr.? ? <fdrake at gmail.com>
"A storm broke loose in my mind."? --Albert Einstein

From alexander.belopolsky at gmail.com  Thu Aug 12 19:39:14 2010
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Thu, 12 Aug 2010 13:39:14 -0400
Subject: [Python-Dev] Remove "unit test needed"
In-Reply-To: <AANLkTimkE+LSPT7Rm7-VQrd6nAzzkGc91=8YLg5qZhsX@mail.gmail.com>
References: <20100812135639.541ac252@pitrou.net>
	<AANLkTi=mst+SpNyi-Np96jqsc9zqFQLnkUEj0pdFUV0m@mail.gmail.com>
	<AANLkTimSc3RRBeQ6NBZcVxD4w_gF9jddyP47h3PEC_xU@mail.gmail.com>
	<AANLkTimkE+LSPT7Rm7-VQrd6nAzzkGc91=8YLg5qZhsX@mail.gmail.com>
Message-ID: <AANLkTik0Y456u+V2DSjF5V=JxUhoO-ZMCpX3rGEj2gPC@mail.gmail.com>

On Thu, Aug 12, 2010 at 1:31 PM, Fred Drake <fdrake at acm.org> wrote:
> On Thu, Aug 12, 2010 at 11:02 AM, Alexander Belopolsky
> <alexander.belopolsky at gmail.com> wrote:
>> I remember there was an idea somewhere to replace "patch" tag with a
>> check-list with boxes for code, tests, and docs. ?I think that would
>> be better than "unit test needed" stage.
>
> Are you suggesting check boxes for what's needed, or for what's present?
>
Please see  http://wiki.python.org/moin/DesiredTrackerFeatures .
Ezio, thanks for the link.

From solipsis at pitrou.net  Thu Aug 12 19:41:51 2010
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Thu, 12 Aug 2010 19:41:51 +0200
Subject: [Python-Dev] Remove "unit test needed"
In-Reply-To: <AANLkTimSc3RRBeQ6NBZcVxD4w_gF9jddyP47h3PEC_xU@mail.gmail.com>
References: <20100812135639.541ac252@pitrou.net>
	<AANLkTi=mst+SpNyi-Np96jqsc9zqFQLnkUEj0pdFUV0m@mail.gmail.com>
	<AANLkTimSc3RRBeQ6NBZcVxD4w_gF9jddyP47h3PEC_xU@mail.gmail.com>
Message-ID: <20100812194151.40476c49@pitrou.net>

On Thu, 12 Aug 2010 11:02:29 -0400
Alexander Belopolsky <alexander.belopolsky at gmail.com> wrote:
> 
> I remember there was an idea somewhere to replace "patch" tag with a
> check-list with boxes for code, tests, and docs.  I think that would
> be better than "unit test needed" stage.

To me the simpler the better. If there's a patch then it's the
reviewer's task to point out what's missing - and that's
context-dependent: some fixes don't need a doc change or a test case
(or, at least, they can do without).

The rationale is that the more complex a system is, the less likely we
are to use it. Our current "keywords" are severely under-used.

Regards

Antoine.

From fuzzyman at voidspace.org.uk  Thu Aug 12 20:09:37 2010
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Thu, 12 Aug 2010 19:09:37 +0100
Subject: [Python-Dev] Fixing #7175: a standard location for
 Python	config files
In-Reply-To: <AANLkTinw4MhvH-ZU+H-F49LJMHwTrFmsxBHa5JescM24@mail.gmail.com>
References: <4C62C01D.6000900@netwok.org>	<rowen-7F4859.22004011082010@news.gmane.org>
	<AANLkTinw4MhvH-ZU+H-F49LJMHwTrFmsxBHa5JescM24@mail.gmail.com>
Message-ID: <4C6438E1.5000201@voidspace.org.uk>

On 12/08/2010 08:26, Tarek Ziad? wrote:
> [snip...]
> Choosing an arbitrary location we think is good on every system is fine
> and non risky I think, as long as Python let the various distribution
> change those paths though configuration.
>
> In fact, that's one of the future goal of the sysconfig module I had in mind.
>
> Instead of having it reading paths from python variables, I would like
> to introduce
> a configuration file global to Python containing all the installation paths, and
> the paths we are currently discussing.
>
> That file could then be changed by distributions depending on their layouts.
>
>    

Yes - this sounds good. +1 It also provides a single place for users who 
are unhappy with the defaults that we choose.

Michael

> It will avoid distributions to hack Python to change those paths.
> For instance, Ubuntu currently patches distutils to change the
> installation paths.
>
> So let's:
>
> - define all the default locations for each system
> - define a sysconfig.cfg file that contains all installation paths,
> for each target system
> - change sysconfig.py so it uses it, instead of the global dicts it
> currently has
>
>
> Regards
> Tarek
>
>    


-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (?BOGUS AGREEMENTS?) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.



From fuzzyman at voidspace.org.uk  Thu Aug 12 20:14:15 2010
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Thu, 12 Aug 2010 19:14:15 +0100
Subject: [Python-Dev] Remove "unit test needed"
In-Reply-To: <20100812135639.541ac252@pitrou.net>
References: <20100812135639.541ac252@pitrou.net>
Message-ID: <4C6439F7.5000706@voidspace.org.uk>

On 12/08/2010 12:56, Antoine Pitrou wrote:
> Hello,
>
> I would like to see ?unit test needed? removed from the workflow menu in
> the bug tracker. The reason is that we don't do test-driven development
> (or, at least, most of us don't) and this stage entry is therefore
> useless and confusing. Saying to someone that an unit test is needed
> happens during the patch review - it isn't a separate stage in itself.
>
> The reason I'm asking is that I've seen some triagers bumping a lot of
> issues to ?unit test needed? lately, and I find this annoying. What we
> need is patches, not unit tests per se.
>
>    

I often see patches without a test, and have assumed this is what this 
stage is for - where a patch is provided without a corresponding test.

On the other hand checkboxes for fix / test / docs sounds fine.

Michael

> Regards
>
> Antoine.
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at 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/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (?BOGUS AGREEMENTS?) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.



From ncoghlan at gmail.com  Thu Aug 12 23:48:22 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 13 Aug 2010 07:48:22 +1000
Subject: [Python-Dev] Fixing #7175: a standard location for Python
	config files
In-Reply-To: <4C63E7E3.3090100@netwok.org>
References: <4C62C01D.6000900@netwok.org>
	<rowen-7F4859.22004011082010@news.gmane.org>
	<AANLkTinw4MhvH-ZU+H-F49LJMHwTrFmsxBHa5JescM24@mail.gmail.com>
	<4C63E7E3.3090100@netwok.org>
Message-ID: <AANLkTinoh3sXWDkzWJFNf==AF8Q32Ga7Jc9jN5+vrFZ6@mail.gmail.com>

2010/8/12 ?ric Araujo <merwok at netwok.org>:
>> Choosing an arbitrary location we think is good on every system is fine
>> and non risky I think, as long as Python let the various distribution
>> change those paths though configuration.
>
> Don?t you have a bootstrapping problem? How do you know where to look at
> the sysconfig file that tells where to look at config files?

Personally, I'm not clear on what a separate syconfig.cfg file offers
over clearly separating the directory configuration settings and
continuing to have distributions patch sysconfig.py directly. The
bootstrapping problem (which would encourage classifying synconfig.cfg
as source code and placing it alongside syscongig.py) is a major part
of that point of view.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From martin at v.loewis.de  Thu Aug 12 23:53:53 2010
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 12 Aug 2010 23:53:53 +0200
Subject: [Python-Dev] mingw support?
In-Reply-To: <20100812150011.GA11541@laptop.gs>
References: <20100807195541.GA13990@laptop.gs>
	<i3n225$osp$1@dough.gmane.org>	<AANLkTi=dc=0brYo34=xaU6D9wH97eB_tTN=b=FBNjLNh@mail.gmail.com>	<9f2ea5ad00140f45fdf639eb0b234aea.squirrel@webmail.uio.no>	<i3q110$ncr$1@dough.gmane.org>
	<20100810140620.GB4464@laptop.gs>	<AANLkTik0QoHNXGgqhbtQKJqrFoC3kxzzomm06sJfZLJ8@mail.gmail.com>	<40b838e9eeeac1852e96a0f5d25d67a0.squirrel@webmail.uio.no>	<AANLkTimfAiHnLkq_6-uU=Xd-2+bZdHa8qn-4kLazbwS6@mail.gmail.com>
	<20100812150011.GA11541@laptop.gs>
Message-ID: <4C646D71.3030400@v.loewis.de>

> My argument goes that one of the biggest differences between the
> GNU/Linux and the Windows way of computing is the barrier between user
> and programmer. In the Windows way, you are either a user or a
> programmer. 

Such arguments are off-topic for python-dev; please use one of the
Linux advocacy forums.

A little bit on-topic, I think that Python actually helps to lower
the barrier between users and programmers on Windows.

Regards,
Martin

From glyph at twistedmatrix.com  Fri Aug 13 00:14:44 2010
From: glyph at twistedmatrix.com (Glyph Lefkowitz)
Date: Thu, 12 Aug 2010 18:14:44 -0400
Subject: [Python-Dev] Fixing #7175: a standard location for
	Python	config files
In-Reply-To: <4C63CD36.4050400@timgolden.me.uk>
References: <4C62C01D.6000900@netwok.org> <4C63C3F1.6000603@timgolden.me.uk>
	<i40hps$5r7$1@dough.gmane.org> <4C63CD36.4050400@timgolden.me.uk>
Message-ID: <A01493B1-61C5-41B8-B673-31A3993FE760@twistedmatrix.com>


On Aug 12, 2010, at 6:30 AM, Tim Golden wrote:

> I don't care how many stats we're doing

You might not, but I certainly do.  And I can guarantee you that the authors of command-line tools that have to start up in under ten seconds, for example 'bzr', care too.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100812/76fec47e/attachment.html>

From solipsis at pitrou.net  Fri Aug 13 00:29:59 2010
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Fri, 13 Aug 2010 00:29:59 +0200
Subject: [Python-Dev] Fixing #7175: a standard location for
	Python	config files
References: <4C62C01D.6000900@netwok.org> <4C63C3F1.6000603@timgolden.me.uk>
	<i40hps$5r7$1@dough.gmane.org> <4C63CD36.4050400@timgolden.me.uk>
	<A01493B1-61C5-41B8-B673-31A3993FE760@twistedmatrix.com>
Message-ID: <20100813002959.4b455cd8@pitrou.net>

On Thu, 12 Aug 2010 18:14:44 -0400
Glyph Lefkowitz <glyph at twistedmatrix.com> wrote:
> 
> On Aug 12, 2010, at 6:30 AM, Tim Golden wrote:
> 
> > I don't care how many stats we're doing
> 
> You might not, but I certainly do.  And I can guarantee you that the
> authors of command-line tools that have to start up in under ten
> seconds, for example 'bzr', care too.

The idea that import time is dominated by stat() calls sounds rather
undemonstrated (and unlikely) to me.

Regards

Antoine.



From victor.stinner at haypocalc.com  Fri Aug 13 01:17:20 2010
From: victor.stinner at haypocalc.com (Victor Stinner)
Date: Fri, 13 Aug 2010 01:17:20 +0200
Subject: [Python-Dev] [RELEASED] Python 3.2 alpha 1
In-Reply-To: <4C55409B.5000409@python.org>
References: <4C55409B.5000409@python.org>
Message-ID: <201008130117.20724.victor.stinner@haypocalc.com>

> ... Highlights are:
> 
> * numerous improvements to the unittest module
> * PEP 3147, support for .pyc repository directories
> * an overhauled GIL implementation that reduces contention
> * many consistency and behavior fixes for numeric operations
> * countless fixes regarding string/unicode issues; among them full
>   support for a bytes environment (filenames, environment variables)
> * a sysconfig module to access configuration information
> * a pure-Python implementation of the datetime module
> * additions to the shutil module, among them archive file support
> * improvements to pdb, the Python debugger

Hey, Python 3(.2) becomes more sexy than Python 2(.7)!

-- 
Victor Stinner
http://www.haypocalc.com/

From greg.ewing at canterbury.ac.nz  Fri Aug 13 01:44:12 2010
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Fri, 13 Aug 2010 11:44:12 +1200
Subject: [Python-Dev] mingw support?
In-Reply-To: <AANLkTikaafnJJBgiYfJf+v1B21RizYSjEzMBKRkBdLVL@mail.gmail.com>
References: <20100807195541.GA13990@laptop.gs> <i3n225$osp$1@dough.gmane.org>
	<AANLkTi=dc=0brYo34=xaU6D9wH97eB_tTN=b=FBNjLNh@mail.gmail.com>
	<9f2ea5ad00140f45fdf639eb0b234aea.squirrel@webmail.uio.no>
	<i3q110$ncr$1@dough.gmane.org> <20100810140620.GB4464@laptop.gs>
	<AANLkTik0QoHNXGgqhbtQKJqrFoC3kxzzomm06sJfZLJ8@mail.gmail.com>
	<40b838e9eeeac1852e96a0f5d25d67a0.squirrel@webmail.uio.no>
	<AANLkTimfAiHnLkq_6-uU=Xd-2+bZdHa8qn-4kLazbwS6@mail.gmail.com>
	<20100812150011.GA11541@laptop.gs>
	<AANLkTikaafnJJBgiYfJf+v1B21RizYSjEzMBKRkBdLVL@mail.gmail.com>
Message-ID: <4C64874C.6040206@canterbury.ac.nz>

Cesare Di Mauro wrote:

> You must suggest at least an equivalent "free" alternative to make the 
> switch convenient.
> 
> Otherwise we are talking about philosophy or religion, and nobody will 
> change his ideas.

I think the point is that *because* people don't want to change
their ideas, it would be good to have a mingw-based alternative.
Otherwise everyone is forced to convert to the Windows religion.

-- 
Greg


From fuzzyman at voidspace.org.uk  Fri Aug 13 01:37:19 2010
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Fri, 13 Aug 2010 00:37:19 +0100
Subject: [Python-Dev] mingw support?
In-Reply-To: <4C64874C.6040206@canterbury.ac.nz>
References: <20100807195541.GA13990@laptop.gs>
	<i3n225$osp$1@dough.gmane.org>	<AANLkTi=dc=0brYo34=xaU6D9wH97eB_tTN=b=FBNjLNh@mail.gmail.com>	<9f2ea5ad00140f45fdf639eb0b234aea.squirrel@webmail.uio.no>	<i3q110$ncr$1@dough.gmane.org>
	<20100810140620.GB4464@laptop.gs>	<AANLkTik0QoHNXGgqhbtQKJqrFoC3kxzzomm06sJfZLJ8@mail.gmail.com>	<40b838e9eeeac1852e96a0f5d25d67a0.squirrel@webmail.uio.no>	<AANLkTimfAiHnLkq_6-uU=Xd-2+bZdHa8qn-4kLazbwS6@mail.gmail.com>	<20100812150011.GA11541@laptop.gs>	<AANLkTikaafnJJBgiYfJf+v1B21RizYSjEzMBKRkBdLVL@mail.gmail.com>
	<4C64874C.6040206@canterbury.ac.nz>
Message-ID: <4C6485AF.1020704@voidspace.org.uk>

On 13/08/2010 00:44, Greg Ewing wrote:
> Cesare Di Mauro wrote:
>
>> You must suggest at least an equivalent "free" alternative to make 
>> the switch convenient.
>>
>> Otherwise we are talking about philosophy or religion, and nobody 
>> will change his ideas.
>
> I think the point is that *because* people don't want to change
> their ideas, it would be good to have a mingw-based alternative.
> Otherwise everyone is forced to convert to the Windows religion.
>
You mean people using Windows are forced to use Windows?

Michael

-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (?BOGUS AGREEMENTS?) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.



From steve at pearwood.info  Fri Aug 13 02:43:30 2010
From: steve at pearwood.info (Steven D'Aprano)
Date: Fri, 13 Aug 2010 10:43:30 +1000
Subject: [Python-Dev] Fixing #7175: a standard location for Python
	config files
In-Reply-To: <i40hps$5r7$1@dough.gmane.org>
References: <4C62C01D.6000900@netwok.org> <4C63C3F1.6000603@timgolden.me.uk>
	<i40hps$5r7$1@dough.gmane.org>
Message-ID: <201008131043.31383.steve@pearwood.info>

On Thu, 12 Aug 2010 08:18:27 pm Steve Holden wrote:
> One might make a case that all configuration data should be stored in
> a single SQLite database (with a suitable API to hide the relational
> nature of the store).

-1

Please don't even *consider* such a thing. Haven't we learned from 
Firefox? I for one am getting heartily sick and tired of having 
to "fix" (that is, throw away) corrupted Firefox databases. Please 
don't go down that path.


-- 
Steven D'Aprano

From a.badger at gmail.com  Fri Aug 13 03:02:34 2010
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Thu, 12 Aug 2010 21:02:34 -0400
Subject: [Python-Dev] Fixing #7175: a standard location for Python
 config files
In-Reply-To: <AANLkTinoh3sXWDkzWJFNf==AF8Q32Ga7Jc9jN5+vrFZ6@mail.gmail.com>
References: <4C62C01D.6000900@netwok.org>
	<rowen-7F4859.22004011082010@news.gmane.org>
	<AANLkTinw4MhvH-ZU+H-F49LJMHwTrFmsxBHa5JescM24@mail.gmail.com>
	<4C63E7E3.3090100@netwok.org>
	<AANLkTinoh3sXWDkzWJFNf==AF8Q32Ga7Jc9jN5+vrFZ6@mail.gmail.com>
Message-ID: <20100813010234.GR12586@unaka.lan>

On Fri, Aug 13, 2010 at 07:48:22AM +1000, Nick Coghlan wrote:
> 2010/8/12 ?ric Araujo <merwok at netwok.org>:
> >> Choosing an arbitrary location we think is good on every system is fine
> >> and non risky I think, as long as Python let the various distribution
> >> change those paths though configuration.
> >
> > Don?t you have a bootstrapping problem? How do you know where to look at
> > the sysconfig file that tells where to look at config files?

I'd hardcode a list of locations.
  [os.path.join(os.path.dirname(__file__), 'sysconfig.cfg'),
   os.path.join('/etc', 'sysconfig.cfg')]

The distributor has a limited choice of options on where to look.

A good alternative would be to make the config file overridable.  That way
you can have sysconfig.cfg next to sysconfig.py or in a known config
directory relative to the python stdlib install but also let the
distributions and individual sites override the defaults by making changes
to /etc/python3/sysconfig.cfg for instance.

> 
> Personally, I'm not clear on what a separate syconfig.cfg file offers
> over clearly separating the directory configuration settings and
> continuing to have distributions patch sysconfig.py directly. The
> bootstrapping problem (which would encourage classifying synconfig.cfg
> as source code and placing it alongside syscongig.py) is a major part
> of that point of view.
> 
Here's some advantages but some of them are of dubious worth:

* Allows users/site-administrators to change paths and not have packaging
  systems overwrite the changes.
* Makes it conceptually cleaner to make this overridable via user defined
  config files since  it's now a matter of parsing several config files
  instead of having a hardcoded value in the file and overridable values
  outside of it.
* Allows sites to add additional paths to the config file.
* Makes it clear to distributions that the values in the config file are
  available for making changes to rather than having to look for it in code
  and not know the difference between thaat or say, the encoding parameter
  in python2.
* Documents the format to use for overriding the paths if individual sites
  can override the defaults that are shipped in the system version of
  python.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100812/06282a75/attachment.pgp>

From merwok at netwok.org  Fri Aug 13 03:15:28 2010
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Fri, 13 Aug 2010 03:15:28 +0200
Subject: [Python-Dev] Fixing #7175: a standard location for Python
 config files
In-Reply-To: <20100813010234.GR12586@unaka.lan>
References: <4C62C01D.6000900@netwok.org>
	<rowen-7F4859.22004011082010@news.gmane.org>
	<AANLkTinw4MhvH-ZU+H-F49LJMHwTrFmsxBHa5JescM24@mail.gmail.com>
	<4C63E7E3.3090100@netwok.org>
	<AANLkTinoh3sXWDkzWJFNf==AF8Q32Ga7Jc9jN5+vrFZ6@mail.gmail.com>
	<20100813010234.GR12586@unaka.lan>
Message-ID: <4C649CB0.40105@netwok.org>

> A good alternative would be to make the config file overridable.  That way
> you can have sysconfig.cfg next to sysconfig.py or in a known config
> directory relative to the python stdlib install but also let the
> distributions and individual sites override the defaults by making changes
> to /etc/python3/sysconfig.cfg for instance.

Putting configuration files next to source code does not agree with the
FHS. Your message gave me an idea though: Some function could be called
in sitecustomize (symlinked from /etc on Debian e.g.) to set the path to
sysconfig.cfg.


From dalcinl at gmail.com  Fri Aug 13 04:11:48 2010
From: dalcinl at gmail.com (Lisandro Dalcin)
Date: Thu, 12 Aug 2010 23:11:48 -0300
Subject: [Python-Dev] mingw support?
In-Reply-To: <4C6485AF.1020704@voidspace.org.uk>
References: <20100807195541.GA13990@laptop.gs> <i3n225$osp$1@dough.gmane.org>
	<AANLkTi=dc=0brYo34=xaU6D9wH97eB_tTN=b=FBNjLNh@mail.gmail.com>
	<9f2ea5ad00140f45fdf639eb0b234aea.squirrel@webmail.uio.no>
	<i3q110$ncr$1@dough.gmane.org> <20100810140620.GB4464@laptop.gs>
	<AANLkTik0QoHNXGgqhbtQKJqrFoC3kxzzomm06sJfZLJ8@mail.gmail.com>
	<40b838e9eeeac1852e96a0f5d25d67a0.squirrel@webmail.uio.no>
	<AANLkTimfAiHnLkq_6-uU=Xd-2+bZdHa8qn-4kLazbwS6@mail.gmail.com>
	<20100812150011.GA11541@laptop.gs>
	<AANLkTikaafnJJBgiYfJf+v1B21RizYSjEzMBKRkBdLVL@mail.gmail.com>
	<4C64874C.6040206@canterbury.ac.nz>
	<4C6485AF.1020704@voidspace.org.uk>
Message-ID: <AANLkTikru+Tm9bVZnK0-8Kn3qo76N9HdErROgs-8y_N1@mail.gmail.com>

On 12 August 2010 20:37, Michael Foord <fuzzyman at voidspace.org.uk> wrote:
> On 13/08/2010 00:44, Greg Ewing wrote:
>>
>> Cesare Di Mauro wrote:
>>
>>> You must suggest at least an equivalent "free" alternative to make the
>>> switch convenient.
>>>
>>> Otherwise we are talking about philosophy or religion, and nobody will
>>> change his ideas.
>>
>> I think the point is that *because* people don't want to change
>> their ideas, it would be good to have a mingw-based alternative.
>> Otherwise everyone is forced to convert to the Windows religion.
>>
> You mean people using Windows are forced to use Windows?
>

I would say people that want to support Windows but are not using it.


-- 
Lisandro Dalcin
---------------
CIMEC (INTEC/CONICET-UNL)
Predio CONICET-Santa Fe
Colectora RN 168 Km 472, Paraje El Pozo
Tel: +54-342-4511594 (ext 1011)
Tel/Fax: +54-342-4511169

From andrew at bemusement.org  Fri Aug 13 04:00:37 2010
From: andrew at bemusement.org (Andrew Bennetts)
Date: Fri, 13 Aug 2010 12:00:37 +1000
Subject: [Python-Dev] Fixing #7175: a standard location for Python
 config files
In-Reply-To: <20100813002959.4b455cd8@pitrou.net>
References: <4C62C01D.6000900@netwok.org> <4C63C3F1.6000603@timgolden.me.uk>
	<i40hps$5r7$1@dough.gmane.org> <4C63CD36.4050400@timgolden.me.uk>
	<A01493B1-61C5-41B8-B673-31A3993FE760@twistedmatrix.com>
	<20100813002959.4b455cd8@pitrou.net>
Message-ID: <20100813020037.GA3328@aihal.home.puzzling.org>

Antoine Pitrou wrote:
> On Thu, 12 Aug 2010 18:14:44 -0400
> Glyph Lefkowitz <glyph at twistedmatrix.com> wrote:
> > 
> > On Aug 12, 2010, at 6:30 AM, Tim Golden wrote:
> > 
> > > I don't care how many stats we're doing
> > 
> > You might not, but I certainly do.  And I can guarantee you that the
> > authors of command-line tools that have to start up in under ten
> > seconds, for example 'bzr', care too.
> 
> The idea that import time is dominated by stat() calls sounds rather
> undemonstrated (and unlikely) to me.

In the case of bzr startup, the exact breakdown varies depending on a
range of factors like OS and whether the relevant parts of the
filesystem are in the OS cache or not (i.e. is this the first time the
user has run bzr since booting?).

The short answer is that the number of stat calls isn't really the
problem at the moment for bzr, at least not compared to the number of
*directories* Python searches, and the amount of non-trivial work done
at import time by many modules.  But... Your Mileage May Vary.

Here's the longer answer:

I think some stats about this have been posted to this list before, but
some points of interest from the top of my head:

 * the cost of trying and failing to open foomodule.so + foo.so +
   foo.pyc + foo.py in a directory isn't much greater than trying to
   open just one on them.  Once the OS has cached the directory entries
   for that directory subsequent lookups in that directory are fast.
   The experiement is fairly easy:
     - strace -e open,stat64 -o py.strace python -c "something..."
     - by hand, create a .C file that repeats all the stat and open
       in py.strace (it's pretty easy to munge into valid C)
     - and also create one with only the *successful* stat and open
       calls
     - compare them (using /proc/sys/vm/drop_caches or whatever as
       appropriate)
 * each directory probed is a significant cost, especially in the
   "cold boot" case.  So every in sys.path, and every subdirectory of a
   package.
 * that said, Windows seems much slower than Linux on equivalent
   hardware, perhaps attempting to open files is intrinsically more
   expensive there?  Certainly it's not safe to assume conclusions drawn
   on Linux will apply equally well on Windows, or vice versa.
 * modules with many class/function definitions are measurably slower
   than smaller modules.
 * module-level re.compile calls and other non-trivial operations are to
   be avoided, but many modules you depend on will do that.  This
   matters so much that bzr monkey-patches the re module to make
   re.compile lazy.  Try grepping the stdlib to see how many modules do
   re.compile at import time (including as default values of keyword
   args)!
 * it's death by a thousand cuts: each module import probably imports a
   dozen others... by far the simplest way to reduce startup time is to
   just import less modules.  Lazy module imports (bzrlib.lazy_import or
   hg's demandload or whatever) help a lot, and I wish they were a
   builtin feature of Python.
 * I haven't even mentioned NFS or other network filesystems, but you
   can bet they change the picture significantly.

-Andrew.


From a.badger at gmail.com  Fri Aug 13 04:46:24 2010
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Thu, 12 Aug 2010 22:46:24 -0400
Subject: [Python-Dev] Fixing #7175: a standard location for Python
 config files
In-Reply-To: <4C649CB0.40105@netwok.org>
References: <4C62C01D.6000900@netwok.org>
	<rowen-7F4859.22004011082010@news.gmane.org>
	<AANLkTinw4MhvH-ZU+H-F49LJMHwTrFmsxBHa5JescM24@mail.gmail.com>
	<4C63E7E3.3090100@netwok.org>
	<AANLkTinoh3sXWDkzWJFNf==AF8Q32Ga7Jc9jN5+vrFZ6@mail.gmail.com>
	<20100813010234.GR12586@unaka.lan> <4C649CB0.40105@netwok.org>
Message-ID: <20100813024624.GS12586@unaka.lan>

On Fri, Aug 13, 2010 at 03:15:28AM +0200, ?ric Araujo wrote:
> > A good alternative would be to make the config file overridable.  That way
> > you can have sysconfig.cfg next to sysconfig.py or in a known config
> > directory relative to the python stdlib install but also let the
> > distributions and individual sites override the defaults by making changes
> > to /etc/python3/sysconfig.cfg for instance.
> 
> Putting configuration files next to source code does not agree with the
> FHS.
>
That depends -- sometimes a config file is actually a data file.  In
following the FHS, a linux distribtuion and system administrators want to
make sure a sysadmin never needs to modify a file outside of /etc for
configuration.  However, if you had a config file that is installed with
python and not meant to be modified next to the code and the sysadmin is
able to customize python's behaviour by copying lines from that file to
a file in /etc/ that they do modify, that's perfectly fine.  Where
developers often run afoul of the FHS is creating a configuration option
that does not live in a file in /etc/ (either because they think it's data
but system administrators routinely want to modify.it or because they don't
care about the FHS and just want to put everything in a single directory)
and hte system admin has no means to set that option permanently but to
modify the files outside of /etc/.

>
> Your message gave me an idea though: Some function could be called
> in sitecustomize (symlinked from /etc on Debian e.g.) to set the path to
> sysconfig.cfg.
> 
I hope that you mean that the actual file lives in /etc/ and then a symlink
in the stdlib points to it.  That sounds acceptable from an FHS view but
it's a bad idea.  Most of the config files in /etc/ are declarative.  A few
of the files in /etc/ are imperative (for instance, init scripts) and
distributions frequently debate whether these are actually config files or
files misplaced in /etc/ for historical reasons.  Fedora, for instance, does
not mark initscripts as config -- all configuration of initscripts are done
by setting shell variables in a different file which is marked config.

(Files marked config in a package manager generally are treated differently
on upgrades.  If the files have been modified since install, they are either
not replaced or, when replaced, a backup is made so that the system
administrator can merge their local changes.)

The problem with having imperative constructs in /etc/ is that they're much
harder (perhaps impossible) to fix up when changes have to be made at the
system packaging level.  Let's say that you hard code this into the
sitecustomize.py when you ship it for the first time on Fedora:

  siteconfig_cfg = '/etc/siteconfig.cfg'
 
The system administrator installs this package and then does some unrelated
customization for his site in the file:

  if sys.version_info[:2] == '3.0':
      sys.path.append('/opt/python3.0')
      siteconfig_cfg = '/etc/siteconfig30.cfg'
  elif sys.version_info[:2] == '3.1':
      sys.path.append(os.environ['USER'] + '/opt/python3.1')
      siteconfig_cfg = '/etc/siteconfig31.cfg'
  elif sys.version_info[:2] == '3.2':
      sys.path.append(os.environ['USER'] + '/opt/python3.2')
      siteconfig_cfg = '/etc/siteconfig.cfg'
  # [...] Do other strange stuff because if it's possible, someone will.

Now, when we update to python3.3 we decide to move siteconfig.cfg into
/etc/python3.3/.  But, because the system admin has modified that file so
heavily, we don't update that file.  This means the updated python is broken
out of the box.

If you're enamoured of symlinks, you can do this directly with the config
file instead of using sitecustomize::

  /etc/python3.2/sysconfig.cfg
  /usr/lib64/python3.2/sysconfig.cfg => /etc/python3.2/sysconfig.cfg

as a third alternative.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100812/3bac2cd5/attachment-0001.pgp>

From cournape at gmail.com  Fri Aug 13 06:31:00 2010
From: cournape at gmail.com (David Cournapeau)
Date: Fri, 13 Aug 2010 13:31:00 +0900
Subject: [Python-Dev] Fixing #7175: a standard location for Python
	config files
In-Reply-To: <20100813002959.4b455cd8@pitrou.net>
References: <4C62C01D.6000900@netwok.org> <4C63C3F1.6000603@timgolden.me.uk>
	<i40hps$5r7$1@dough.gmane.org> <4C63CD36.4050400@timgolden.me.uk>
	<A01493B1-61C5-41B8-B673-31A3993FE760@twistedmatrix.com>
	<20100813002959.4b455cd8@pitrou.net>
Message-ID: <AANLkTi=bQuTgmmdSs7G+614P7Xtf+DWTDadZ-0OJZRtp@mail.gmail.com>

On Fri, Aug 13, 2010 at 7:29 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Thu, 12 Aug 2010 18:14:44 -0400
> Glyph Lefkowitz <glyph at twistedmatrix.com> wrote:
>>
>> On Aug 12, 2010, at 6:30 AM, Tim Golden wrote:
>>
>> > I don't care how many stats we're doing
>>
>> You might not, but I certainly do. ?And I can guarantee you that the
>> authors of command-line tools that have to start up in under ten
>> seconds, for example 'bzr', care too.
>
> The idea that import time is dominated by stat() calls sounds rather
> undemonstrated (and unlikely) to me.

It may be, depending on what you import. I certainly have seen (and
profiled) it. In my experience, stat calls and regex compilation often
come at the top of the culprits for slow imports. In the case of
setuptools namespace package, there was a thread on 23rd april on
distutils-sig about this issue: most of the slowdown came from
unneeded stat (and symlink translations).

cheers,

David

From stephen at xemacs.org  Fri Aug 13 07:23:59 2010
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Fri, 13 Aug 2010 14:23:59 +0900
Subject: [Python-Dev] mingw support?
In-Reply-To: <4C6485AF.1020704@voidspace.org.uk>
References: <20100807195541.GA13990@laptop.gs> <i3n225$osp$1@dough.gmane.org>
	<AANLkTi=dc=0brYo34=xaU6D9wH97eB_tTN=b=FBNjLNh@mail.gmail.com>
	<9f2ea5ad00140f45fdf639eb0b234aea.squirrel@webmail.uio.no>
	<i3q110$ncr$1@dough.gmane.org> <20100810140620.GB4464@laptop.gs>
	<AANLkTik0QoHNXGgqhbtQKJqrFoC3kxzzomm06sJfZLJ8@mail.gmail.com>
	<40b838e9eeeac1852e96a0f5d25d67a0.squirrel@webmail.uio.no>
	<AANLkTimfAiHnLkq_6-uU=Xd-2+bZdHa8qn-4kLazbwS6@mail.gmail.com>
	<20100812150011.GA11541@laptop.gs>
	<AANLkTikaafnJJBgiYfJf+v1B21RizYSjEzMBKRkBdLVL@mail.gmail.com>
	<4C64874C.6040206@canterbury.ac.nz>
	<4C6485AF.1020704@voidspace.org.uk>
Message-ID: <87y6cbm6fk.fsf@uwakimon.sk.tsukuba.ac.jp>

Michael Foord writes:

 > > I think the point is that *because* people don't want to change
 > > their ideas, it would be good to have a mingw-based alternative.
 > > Otherwise everyone is forced to convert to the Windows religion.

 > You mean people using Windows are forced to use Windows?

By far not all, but some are.  Like me, I only use Windows when my
boss holds up a pink paper and says "shall I sign this?"  So far I
haven't felt a need to build Python on Windows, but if I did I would
strongly prefer to use a familiar (to me) build system based on the
autotools and GCC.

Because I haven't felt that need, I don't think MSYS/mingw support is
a big deal.  But apparently there are a few people whose Windows use
case is characterized both by platform coercion and a desire to build
Python themselves.

The question is "who will support those folks?"  I don't see any
reason why you or Martin should support MSYS/mingw if you don't want
to, but please don't put down the folks who ask for it.  Just say "no,
it's not worth it".  Or maybe, "if you want to do the work, I might
contribute some reviews."  Or whatever.

From stephen at xemacs.org  Fri Aug 13 07:39:05 2010
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Fri, 13 Aug 2010 14:39:05 +0900
Subject: [Python-Dev] Fixing #7175: a standard location for
 Python	config files
In-Reply-To: <4C63D85D.1020409@voidspace.org.uk>
References: <4C62C01D.6000900@netwok.org> <4C63C3F1.6000603@timgolden.me.uk>
	<i40hps$5r7$1@dough.gmane.org> <4C63CF8E.1090308@voidspace.org.uk>
	<4C63D2E5.80606@timgolden.me.uk>
	<4C63D85D.1020409@voidspace.org.uk>
Message-ID: <87wrrvm5qe.fsf@uwakimon.sk.tsukuba.ac.jp>

Michael Foord writes:

 > How is ~/python not memorable or consistent? (And cross-platform
 > memorability and consistency is valuable too.)

But what does "~" mean on Windows?  Inside of Python you can have a
consistent definition, but that doesn't help people whose installer
gets mixed signals so Python itself is in the wrong place, or who are
using external tools (uninstaller, editor, application, etc) that work
on or with Python.

I'm not arguing for use of AppData, but at least it's easy to explain,
and easy to implement, for consistency.

 > Another issue is discoverability. Many users won't know about these
 > config files unless they *see* them.

OK, maybe AppData's out.

 > In fact for Windows the *correct* thing to do is probably to use
 > the registry and then provide a graphical tool for editing the
 > values. If you're arguing for consistency why not argue for this?

Sounds reasonable to me.  Except Python's standard GUI is probably not
up to Windows standards of beauty....




From cesare.di.mauro at gmail.com  Fri Aug 13 09:13:13 2010
From: cesare.di.mauro at gmail.com (Cesare Di Mauro)
Date: Fri, 13 Aug 2010 09:13:13 +0200
Subject: [Python-Dev] mingw support?
In-Reply-To: <4C64874C.6040206@canterbury.ac.nz>
References: <20100807195541.GA13990@laptop.gs> <i3n225$osp$1@dough.gmane.org>
	<AANLkTi=dc=0brYo34=xaU6D9wH97eB_tTN=b=FBNjLNh@mail.gmail.com>
	<9f2ea5ad00140f45fdf639eb0b234aea.squirrel@webmail.uio.no>
	<i3q110$ncr$1@dough.gmane.org> <20100810140620.GB4464@laptop.gs>
	<AANLkTik0QoHNXGgqhbtQKJqrFoC3kxzzomm06sJfZLJ8@mail.gmail.com>
	<40b838e9eeeac1852e96a0f5d25d67a0.squirrel@webmail.uio.no>
	<AANLkTimfAiHnLkq_6-uU=Xd-2+bZdHa8qn-4kLazbwS6@mail.gmail.com>
	<20100812150011.GA11541@laptop.gs>
	<AANLkTikaafnJJBgiYfJf+v1B21RizYSjEzMBKRkBdLVL@mail.gmail.com>
	<4C64874C.6040206@canterbury.ac.nz>
Message-ID: <AANLkTinMJbwyVoX1VYue3bxjqmh_xbXdZDHTkgXjHma1@mail.gmail.com>

2010/8/13 Greg Ewing <greg.ewing at canterbury.ac.nz>

> Cesare Di Mauro wrote:
>
>  You must suggest at least an equivalent "free" alternative to make the
>> switch convenient.
>>
>> Otherwise we are talking about philosophy or religion, and nobody will
>> change his ideas.
>>
>
>

I think the point is that *because* people don't want to change
> their ideas, it would be good to have a mingw-based alternative.
> Otherwise everyone is forced to convert to the Windows religion.
>
> --
> Greg


I like to use Windows because it's a comfortable and productive environment,
certainly not because someone forced me to use it.

Also, I have limited time, so I want to spend it the better I can, focusing
on solving real problems. Setup, Next, Next, Finish, and I want it working
without thinking about anything else.

It's a philosophy similar to Python: you don't need to know if the platform
where it's running is 32 or 64 bits, little or big endian, the operating
system, and so on. Just launch it and start typing code: it'll work.

It can be also a matter of taste. I like graphical environments since the
old Amiga days. If I need a shell, I greatly prefer Python.

Anyway, for Windows there's cygwin too, and Python works. But after some
months I replaced it with native Windows tools (with VisualStudio on top): I
work much, much better this way.

If someone is interested in a mingw port, he should consider about having
decent alternatives to what a Windows user can found on his platform,
otherwise it'll be just pure exercise or a faith matter, since nobody will
use it concretely on a daily work.

Give users a better choice, and I don't see logical reasons because they'll
not change their mind.

My 2 cents.

Cesare
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100813/59b1d28c/attachment.html>

From martin at v.loewis.de  Fri Aug 13 10:57:01 2010
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 13 Aug 2010 10:57:01 +0200
Subject: [Python-Dev] mingw support?
In-Reply-To: <87y6cbm6fk.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <20100807195541.GA13990@laptop.gs>
	<i3n225$osp$1@dough.gmane.org>	<AANLkTi=dc=0brYo34=xaU6D9wH97eB_tTN=b=FBNjLNh@mail.gmail.com>	<9f2ea5ad00140f45fdf639eb0b234aea.squirrel@webmail.uio.no>	<i3q110$ncr$1@dough.gmane.org>
	<20100810140620.GB4464@laptop.gs>	<AANLkTik0QoHNXGgqhbtQKJqrFoC3kxzzomm06sJfZLJ8@mail.gmail.com>	<40b838e9eeeac1852e96a0f5d25d67a0.squirrel@webmail.uio.no>	<AANLkTimfAiHnLkq_6-uU=Xd-2+bZdHa8qn-4kLazbwS6@mail.gmail.com>	<20100812150011.GA11541@laptop.gs>	<AANLkTikaafnJJBgiYfJf+v1B21RizYSjEzMBKRkBdLVL@mail.gmail.com>	<4C64874C.6040206@canterbury.ac.nz>	<4C6485AF.1020704@voidspace.org.uk>
	<87y6cbm6fk.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <4C6508DD.7080503@v.loewis.de>

> The question is "who will support those folks?"  I don't see any
> reason why you or Martin should support MSYS/mingw if you don't want
> to, but please don't put down the folks who ask for it.  Just say "no,
> it's not worth it".  Or maybe, "if you want to do the work, I might
> contribute some reviews."  Or whatever.

The problem really is that when people ask for MingW support, they mean
all kinds of things, and they "can't agree" among themselves what that
is. Some want cross-compiling (i.e. compile using mingw on Linux). Some
want autoconf for mingw with msys. Some want autoconf for mingw with
cygwin. Some want to replace the build system entirely, and have the
new build system support mingw (and claim that you otherwise can't get
"good" mingw support).

It's not that I'm objecting mingw support per se, but have my issues
with each individual patch proposed so far. As for reviewing: people
proposing mingw patches somehow always arrive at very large patches.
Reviewing them is very difficult also.

Regards,
Martin

From ziade.tarek at gmail.com  Fri Aug 13 12:15:49 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 13 Aug 2010 12:15:49 +0200
Subject: [Python-Dev] Fixing #7175: a standard location for Python
	config files
In-Reply-To: <AANLkTinoh3sXWDkzWJFNf==AF8Q32Ga7Jc9jN5+vrFZ6@mail.gmail.com>
References: <4C62C01D.6000900@netwok.org>
	<rowen-7F4859.22004011082010@news.gmane.org>
	<AANLkTinw4MhvH-ZU+H-F49LJMHwTrFmsxBHa5JescM24@mail.gmail.com>
	<4C63E7E3.3090100@netwok.org>
	<AANLkTinoh3sXWDkzWJFNf==AF8Q32Ga7Jc9jN5+vrFZ6@mail.gmail.com>
Message-ID: <AANLkTinPXLP622fGgPX2btfaRZtgiiQ4gVMHUHSuGj1+@mail.gmail.com>

On Thu, Aug 12, 2010 at 11:48 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> 2010/8/12 ?ric Araujo <merwok at netwok.org>:
>>> Choosing an arbitrary location we think is good on every system is fine
>>> and non risky I think, as long as Python let the various distribution
>>> change those paths though configuration.
>>
>> Don?t you have a bootstrapping problem? How do you know where to look at
>> the sysconfig file that tells where to look at config files?

Not if located in a place known/owned by the interpreter whatever the layout is.

>
> Personally, I'm not clear on what a separate syconfig.cfg file offers
> over clearly separating the directory configuration settings and
> continuing to have distributions patch sysconfig.py directly. The
> bootstrapping problem (which would encourage classifying synconfig.cfg
> as source code and placing it alongside syscongig.py) is a major part
> of that point of view.

Sure, sysconfig.cfg would be part of the distribution, and this is not
really different
from code from our core point of view.

But it seems more appealing to give the ability to change installation
locations
through configuration rather than by patching the code, because the latter
also implies that Python behaves differently when patched, and add more
maintenance burden for everybody.

For us for instance, it would be more comfortable to keep most content in
sysconfig private, so we can change them at ease without breaking distributions
that patches it. I would hate to have to do a deprecation cycle if we
change the way
sysconfig internally works.

A documented cfg file feels just more standard-ish to me for this.

Regards.
Tarek

-- 
Tarek Ziad? | http://ziade.org

From esnow at verio.net  Fri Aug 13 17:01:57 2010
From: esnow at verio.net (Eric Snow)
Date: Fri, 13 Aug 2010 11:01:57 -0400
Subject: [Python-Dev] Proposed tweaks to functools.wraps
In-Reply-To: <AANLkTimQhkeUWHBLrsmW+JDOMimgjnpxihUh1L894Zoz@mail.gmail.com>
References: <AANLkTimQhkeUWHBLrsmW+JDOMimgjnpxihUh1L894Zoz@mail.gmail.com>
Message-ID: <D2F744D05ED19D45A4A7757F49274A8B03B95E67@IAD-WPRD-XCHB01.corp.verio.net>

Actually, what is the problem with having all decorators add a __decorated__ to the function that ultimately gets returned, pointing to the function they decorated?  I guess I never saw that discussion.  Perhaps set it to None when the decorator is the same as the decorated (no wrapping involved).  The alternative is sifting through closures, trying to figure out which is the decorated function.  Finding the original decorated function has been a real pain, particularly when a function has more than one closure cell.

-eric

-----Original Message-----
From: python-dev-bounces+esnow=verio.net at python.org [mailto:python-dev-bounces+esnow=verio.net at python.org] On Behalf Of Nick Coghlan
Sent: Tuesday, August 10, 2010 8:31 PM
To: python-dev at python.org
Subject: [Python-Dev] Proposed tweaks to functools.wraps

Based on a pair of tracker issues (#3445 and #9396) I'm considering a
couple of adjustments to functools.wraps for 3.2.

The first (#3445) is a request from ages ago to make update_wrapper
more forgiving when it encounters a missing attribute. Instead of
throwing AttributeError (as it does now), it would just skip the
missing attribute. This would allow wraps to be used with other
callables that don't fully mimic the function API. I was initially
opposed to the idea, but over time I've come to think this is a case
where practicality beats purity (since that really sums up
functools.wraps in general - it is already the case that the copied
info isn't quite right for the decorated function, but it's still
better than using the wrapper function's own metadata).

The second (#9396) came up in the context of the new cache decorators
added to functools, and allowing applications to choose their own
caching strategies. I suggested exposing the original (uncached)
function, and Raymond suggested that the easiest way to enable that
would be for functools.update_wrapper to add a new attribute that
provides a reference to the original function. Some time back, we
considered doing this automatically as an integral part of decoration,
but decided that wasn't appropriate. However, building it into the
explicit wrapping functions makes sense to me. To avoid namespace
conflicts, I plan to use "__wraps__" as the name for the reference to
the original function.

Thoughts? Concerns? Better ideas?

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
_______________________________________________
Python-Dev mailing list
Python-Dev at python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/esnow%40verio.net


This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free.  Thank you.

From ncoghlan at gmail.com  Fri Aug 13 18:07:03 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 14 Aug 2010 02:07:03 +1000
Subject: [Python-Dev] Proposed tweaks to functools.wraps
In-Reply-To: <D2F744D05ED19D45A4A7757F49274A8B03B95E67@IAD-WPRD-XCHB01.corp.verio.net>
References: <AANLkTimQhkeUWHBLrsmW+JDOMimgjnpxihUh1L894Zoz@mail.gmail.com>
	<D2F744D05ED19D45A4A7757F49274A8B03B95E67@IAD-WPRD-XCHB01.corp.verio.net>
Message-ID: <AANLkTingvAu04vhTSQT8wrrw_q_Boa0b_m3iib-LSZKX@mail.gmail.com>

On Sat, Aug 14, 2010 at 1:01 AM, Eric Snow <esnow at verio.net> wrote:
> Actually, what is the problem with having all decorators add a __decorated__ to the function that ultimately gets returned, pointing to the function they decorated? ?I guess I never saw that discussion. ?Perhaps set it to None when the decorator is the same as the decorated (no wrapping involved). ?The alternative is sifting through closures, trying to figure out which is the decorated function. ?Finding the original decorated function has been a real pain, particularly when a function has more than one closure cell.

Because decorators don't always return simple wrapper functions -
sometimes they return the original function and sometimes they
completely replace the original function with something else entirely
(which may not be callable, or even mutable). We refused the
temptation to try to guess when it was appropriate to add the
referring attribute.

functools.update_wrapper and functools.wraps are explicit though, so
it's easy to add the attribute there, we just hadn't thought of doing
it before now.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From status at bugs.python.org  Fri Aug 13 18:08:17 2010
From: status at bugs.python.org (Python tracker)
Date: Fri, 13 Aug 2010 18:08:17 +0200 (CEST)
Subject: [Python-Dev] Summary of Python tracker Issues
Message-ID: <20100813160817.20B63780D3@psf.upfronthosting.co.za>


ACTIVITY SUMMARY (2010-08-06 - 2010-08-13)
Python tracker at http://bugs.python.org/

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

Issues stats:
  open    2645 (+42)
  closed 18724 (+83)
  total  21369 (+51)

Open issues with patches: 1107 


Issues opened (42)
==================

#3402: test_nis is hanging on Solaris
http://bugs.python.org/issue3402  reopened by benjamin.peterson

#5416: str.replace does strange things when given a negative count
http://bugs.python.org/issue5416  reopened by rhettinger

#5504: ctypes should work with systems where mmap can't be	PROT_WRITE
http://bugs.python.org/issue5504  reopened by pitrou

#7467: The zipfile module does not check files' CRCs, including in Zi
http://bugs.python.org/issue7467  reopened by pitrou

#8688: distutils sdist is too laze w.r.t. recalculating MANIFEST
http://bugs.python.org/issue8688  reopened by ronaldoussoren

#9323: trace.py bug with the main file being traced
http://bugs.python.org/issue9323  reopened by belopolsky

#9396: Standardise (and publish?) cache handling in standard library
http://bugs.python.org/issue9396  reopened by rhettinger

#9424: Disable unittest.TestCase.assertEquals and assert_ during a re
http://bugs.python.org/issue9424  reopened by michael.foord

#9538: Replace confusing pseudoname 'object' in special methods secti
http://bugs.python.org/issue9538  opened by terry.reedy

#9539: python-2.6.4: test failure in test_distutils due to linking to
http://bugs.python.org/issue9539  opened by valeo

#9542: Create PyUnicode_FSDecoder() function
http://bugs.python.org/issue9542  opened by haypo

#9544: xdrlib.Packer().pack_fstring throws a TypeError when called wi
http://bugs.python.org/issue9544  opened by arnoldp

#9545: Adding _collections to static build
http://bugs.python.org/issue9545  opened by orsenthil

#9548: locale can be imported at startup but relies on too many	libra
http://bugs.python.org/issue9548  opened by pitrou

#9549: Remove sys.setdefaultencoding()
http://bugs.python.org/issue9549  opened by pitrou

#9552: ssl build under Windows always rebuilds OpenSSL
http://bugs.python.org/issue9552  opened by pitrou

#9553: test_argparse.py: 80 failures if COLUMNS env var set to a valu
http://bugs.python.org/issue9553  opened by denversc

#9554: test_argparse.py: use new unittest features
http://bugs.python.org/issue9554  opened by denversc

#9556: Specifying the time a TimedRotatingFileHandler rotates
http://bugs.python.org/issue9556  opened by ronaldoussoren

#9557: test_mailbox failure under a Windows VM
http://bugs.python.org/issue9557  opened by pitrou

#9558: build_ext fails on VS8.0
http://bugs.python.org/issue9558  opened by ocean-city

#9559: mailbox.mbox creates new file when adding message to mbox
http://bugs.python.org/issue9559  opened by chrisisbd

#9560: platform.py: use -b option for file	command	in	_syscmd_file()
http://bugs.python.org/issue9560  opened by haypo

#9561: distutils: set encoding to utf-8 for input and output files
http://bugs.python.org/issue9561  opened by haypo

#9562: Slightly misleading wording in documentation of dict.update
http://bugs.python.org/issue9562  opened by MLModel

#9566: Compilation warnings under x64 Windows
http://bugs.python.org/issue9566  opened by pitrou

#9567: Add attribute pointing to wrapped function in functools.update
http://bugs.python.org/issue9567  opened by eric.araujo

#9568: test_urllib2_localnet fails on OS X 10.3
http://bugs.python.org/issue9568  opened by ned.deily

#9569: Add tests for posix.mknod() and posix.mkfifo()
http://bugs.python.org/issue9569  opened by baikie

#9571: argparse: Allow the use of -- to break out of nargs and into s
http://bugs.python.org/issue9571  opened by elsdoerfer

#9572: IOError in test_multiprocessing
http://bugs.python.org/issue9572  opened by flox

#9573: importing a module that executes fork() raises RuntimeError
http://bugs.python.org/issue9573  opened by Alex.Roitman

#9574: complex does not parse strings containing decimals
http://bugs.python.org/issue9574  opened by jdwhitley

#9576: logging.addLevelName in file-based configurations
http://bugs.python.org/issue9576  opened by tarek

#9579: In 3.x, os.confstr() returns garbage if value is longer than 2
http://bugs.python.org/issue9579  opened by baikie

#9580: os.confstr() doesn't decode result according to PEP 383
http://bugs.python.org/issue9580  opened by baikie

#9581: PosixGroupsTester fails as root
http://bugs.python.org/issue9581  opened by pitrou

#9582: documentation line needs rewording
http://bugs.python.org/issue9582  opened by mohrr

#9583: PYTHONOPTIMIZE = 0 is not honored
http://bugs.python.org/issue9583  opened by bukzor

#9584: Allow curly braces in fnmatch
http://bugs.python.org/issue9584  opened by bochecha

#9586: "warning: comparison between pointer and integer" in multiproc
http://bugs.python.org/issue9586  opened by mark.dickinson

#9587: unittest.assertRaises() return the raised exception
http://bugs.python.org/issue9587  opened by denversc



Most recent 15 issues with no replies (15)
==========================================

#9587: unittest.assertRaises() return the raised exception
http://bugs.python.org/issue9587

#9583: PYTHONOPTIMIZE = 0 is not honored
http://bugs.python.org/issue9583

#9582: documentation line needs rewording
http://bugs.python.org/issue9582

#9576: logging.addLevelName in file-based configurations
http://bugs.python.org/issue9576

#9562: Slightly misleading wording in documentation of dict.update
http://bugs.python.org/issue9562

#9559: mailbox.mbox creates new file when adding message to mbox
http://bugs.python.org/issue9559

#9557: test_mailbox failure under a Windows VM
http://bugs.python.org/issue9557

#9552: ssl build under Windows always rebuilds OpenSSL
http://bugs.python.org/issue9552

#9535: Pending signals are inherited by child processes
http://bugs.python.org/issue9535

#9533: metaclass can't derive from ABC
http://bugs.python.org/issue9533

#9523: Improve dbm module
http://bugs.python.org/issue9523

#9521: xml.etree.ElementTree strips XML declaration and procesing ins
http://bugs.python.org/issue9521

#9518: PyModuleDef_HEAD_INIT does not explicitly initialize all field
http://bugs.python.org/issue9518

#9509: argparse FileType raises ugly exception for missing file
http://bugs.python.org/issue9509

#9508: python3.2 reversal of distutils reintrocud macos9 support
http://bugs.python.org/issue9508



Most recent 15 issues waiting for review (15)
=============================================

#9587: unittest.assertRaises() return the raised exception
http://bugs.python.org/issue9587

#9584: Allow curly braces in fnmatch
http://bugs.python.org/issue9584

#9581: PosixGroupsTester fails as root
http://bugs.python.org/issue9581

#9580: os.confstr() doesn't decode result according to PEP 383
http://bugs.python.org/issue9580

#9579: In 3.x, os.confstr() returns garbage if value is longer than 2
http://bugs.python.org/issue9579

#9569: Add tests for posix.mknod() and posix.mkfifo()
http://bugs.python.org/issue9569

#9560: platform.py: use -b option for file	command	in	_syscmd_file()
http://bugs.python.org/issue9560

#9558: build_ext fails on VS8.0
http://bugs.python.org/issue9558

#9554: test_argparse.py: use new unittest features
http://bugs.python.org/issue9554

#9553: test_argparse.py: 80 failures if COLUMNS env var set to a valu
http://bugs.python.org/issue9553

#9548: locale can be imported at startup but relies on too many	libra
http://bugs.python.org/issue9548

#9545: Adding _collections to static build
http://bugs.python.org/issue9545

#9542: Create PyUnicode_FSDecoder() function
http://bugs.python.org/issue9542

#9536: defaultdict doc makes incorrect reference to __missing__ metho
http://bugs.python.org/issue9536

#9535: Pending signals are inherited by child processes
http://bugs.python.org/issue9535



Top 10 most discussed issues (10)
=================================

#9425: Rewrite import machinery to work with unicode paths
http://bugs.python.org/issue9425  21 msgs

#9548: locale can be imported at startup but relies on too many	libra
http://bugs.python.org/issue9548  13 msgs

#9560: platform.py: use -b option for file	command	in	_syscmd_file()
http://bugs.python.org/issue9560  11 msgs

#9584: Allow curly braces in fnmatch
http://bugs.python.org/issue9584  11 msgs

#7467: The zipfile module does not check files' CRCs, including in Zi
http://bugs.python.org/issue7467   9 msgs

#9396: Standardise (and publish?) cache handling in standard library
http://bugs.python.org/issue9396   9 msgs

#3539: Problem with pgen make dependencies in certain circumstances
http://bugs.python.org/issue3539   8 msgs

#9424: Disable unittest.TestCase.assertEquals and assert_ during a re
http://bugs.python.org/issue9424   8 msgs

#9553: test_argparse.py: 80 failures if COLUMNS env var set to a valu
http://bugs.python.org/issue9553   8 msgs

#9574: complex does not parse strings containing decimals
http://bugs.python.org/issue9574   7 msgs



Issues closed (83)
==================

#1485576: Backwards compatibility support for Py_ssize_t
http://bugs.python.org/issue1485576  closed by pitrou

#1475: test_popen fails when the directory contains a space
http://bugs.python.org/issue1475  closed by tim.golden

#1886: Permit to easily use distutils "--formats=tar,gztar,bztar" on 
http://bugs.python.org/issue1886  closed by eric.araujo

#2066: Adding new CNS11643, a *huge* charset,	support in cjkcodecs
http://bugs.python.org/issue2066  closed by haypo

#2304: subprocess under windows fails to quote properly when	shell=Tr
http://bugs.python.org/issue2304  closed by tim.golden

#2443: Define Py_VA_COPY macro as a cross-platform replacement for gc
http://bugs.python.org/issue2443  closed by belopolsky

#2864: etree: Add XPath documentation
http://bugs.python.org/issue2864  closed by flox

#3456: compile python using MinGW
http://bugs.python.org/issue3456  closed by skrah

#3592: Patch to add imp.get_codingspec()
http://bugs.python.org/issue3592  closed by brett.cannon

#3757: threading.local doesn't support cyclic garbage collecting
http://bugs.python.org/issue3757  closed by pitrou

#4608: urllib.request.urlopen does not return an iterable object
http://bugs.python.org/issue4608  closed by flox

#5321: I/O error during one-liner gives no (!) diagnostic (and fails 
http://bugs.python.org/issue5321  closed by skrah

#5479: Add an easy way to provide total ordering now that __cmp__ is 
http://bugs.python.org/issue5479  closed by rhettinger

#5484: subprocess.call() fails for .bat files on Windows, if executab
http://bugs.python.org/issue5484  closed by tim.golden

#6105: json.dumps doesn't respect OrderedDict's iteration order
http://bugs.python.org/issue6105  closed by benjamin.peterson

#6186: test_thread occasionally reports unhandled exceptions on OS X
http://bugs.python.org/issue6186  closed by ned.deily

#6609: zipfile: WindowsError [267] The directory name is invalid
http://bugs.python.org/issue6609  closed by tim.golden

#6678: inspect.currentframe documentation omits optional depth parame
http://bugs.python.org/issue6678  closed by benjamin.peterson

#6751: Default return value in ConfigParser
http://bugs.python.org/issue6751  closed by lukasz.langa

#6786: readline and zero based indexing
http://bugs.python.org/issue6786  closed by terry.reedy

#6869: Embedded python crashed on 4th run, if "ctypes" is used
http://bugs.python.org/issue6869  closed by theller

#6915: os.listdir inconsistenly releases the GIL on win32
http://bugs.python.org/issue6915  closed by pitrou

#7007: Tiny inconsistency in the orthography of "url encoded" in the 
http://bugs.python.org/issue7007  closed by orsenthil

#7037: test_asynchat fails on os x 10.6
http://bugs.python.org/issue7037  closed by mark.dickinson

#7335: int/long discrepancy when formatting zero with "%.0d"
http://bugs.python.org/issue7335  closed by mark.dickinson

#7564: test_ioctl may fail when run in background
http://bugs.python.org/issue7564  closed by flox

#7734: discuss mark-as-invalid trick in heapq docs
http://bugs.python.org/issue7734  closed by rhettinger

#8095: test_urllib2 crashes on OS X 10.3 attempting to retrieve netwo
http://bugs.python.org/issue8095  closed by ned.deily

#8228: pprint, single/multiple items per line parameter
http://bugs.python.org/issue8228  closed by rhettinger

#8280: urllib2 passes fragment identifier to server
http://bugs.python.org/issue8280  closed by orsenthil

#8299: Improve GIL in 2.7
http://bugs.python.org/issue8299  closed by terry.reedy

#8306: ctypes.create_string_buffer should only accept bytes
http://bugs.python.org/issue8306  closed by benjamin.peterson

#8411: New GIL: improve condition variable emulation on NT
http://bugs.python.org/issue8411  closed by pitrou

#8433: buildbot: test_curses failure, getmouse() returned ERR
http://bugs.python.org/issue8433  closed by mark.dickinson

#8457: buildbot: test_asynchat and test_smtplib failures on Tiger: [E
http://bugs.python.org/issue8457  closed by mark.dickinson

#8530: Stringlib fastsearch can read beyond the front of an array
http://bugs.python.org/issue8530  closed by flox

#8666: Allow ConfigParser.get*() to take a default value
http://bugs.python.org/issue8666  closed by lukasz.langa

#8834: Define order of Misc/ACKS entries
http://bugs.python.org/issue8834  closed by belopolsky

#9031: distutils uses invalid "-Wstrict-prototypes" flag when compili
http://bugs.python.org/issue9031  closed by terry.reedy

#9057: Distutils2 needs a home page
http://bugs.python.org/issue9057  closed by eric.araujo

#9292: Dead code in Modules/pyexpat.c
http://bugs.python.org/issue9292  closed by benjamin.peterson

#9345: argparse wrap tests are sensitive to terminal size
http://bugs.python.org/issue9345  closed by bethard

#9386: Bad indentation in urllib import fixer with multiple imports
http://bugs.python.org/issue9386  closed by benjamin.peterson

#9431: 2to3 reapplies fix_dict
http://bugs.python.org/issue9431  closed by benjamin.peterson

#9446: urllib2 tests fail when offline
http://bugs.python.org/issue9446  closed by orsenthil

#9452: configparser support for reading from strings and dictionaries
http://bugs.python.org/issue9452  closed by fdrake

#9507: namedtuple should not hardcode the class name in __repr__
http://bugs.python.org/issue9507  closed by rhettinger

#9511: CharacterEncoderError when reading from sys.stdin from piped i
http://bugs.python.org/issue9511  closed by haypo

#9515: vars() dictionary access to generate variables
http://bugs.python.org/issue9515  closed by r.david.murray

#9519: IDLE cannot do example 4.1 in tutorial (if statements)
http://bugs.python.org/issue9519  closed by r.david.murray

#9534: OrderedDict.__del__ destructor throws AttributeError when proc
http://bugs.python.org/issue9534  closed by rhettinger

#9537: argparse: use OrderedDict to store subparsers
http://bugs.python.org/issue9537  closed by bethard

#9540: argparse: combine subparsers with global positional args
http://bugs.python.org/issue9540  closed by r.david.murray

#9541: node.pre_order() does not do preorder traversal
http://bugs.python.org/issue9541  closed by joe.amenta

#9543: 2.6.6 rc1 socket.py flush() calls del on unbound 'view' variab
http://bugs.python.org/issue9543  closed by ezio.melotti

#9546: buildbot: if a compile error occurs,	the "clean" step is skipp
http://bugs.python.org/issue9546  closed by loewis

#9547: iterator length
http://bugs.python.org/issue9547  closed by benjamin.peterson

#9550: BufferedReader may issue additional read, may cause hang when 
http://bugs.python.org/issue9550  closed by pitrou

#9551: ConfigParser.SafeConfigParser.set fails when no value provided
http://bugs.python.org/issue9551  closed by fdrake

#9555: transient crashes on "x86 XP-4" buildbot: test_file, test_file
http://bugs.python.org/issue9555  closed by flox

#9563: optparse: bad exception handling when giving no value to an op
http://bugs.python.org/issue9563  closed by r.david.murray

#9564: Test issue.
http://bugs.python.org/issue9564  closed by mark.dickinson

#9565: socket :  accept() method not working
http://bugs.python.org/issue9565  closed by r.david.murray

#9570: PEP 383: os.mknod() and os.mkfifo() do not accept surrogateesc
http://bugs.python.org/issue9570  closed by benjamin.peterson

#9575: os.listdir() crashes on some long and deep paths in	Windows 7
http://bugs.python.org/issue9575  closed by tim.golden

#9577: html parser bug related with CDATA sections
http://bugs.python.org/issue9577  closed by r.david.murray

#9578: int() raises UnicodeDecodeError when called on malformed strin
http://bugs.python.org/issue9578  closed by flox

#9585: Largefile detection in configure fails
http://bugs.python.org/issue9585  closed by pitrou

#1546442: subprocess.Popen can't read file object as stdin after seek
http://bugs.python.org/issue1546442  closed by terry.reedy

#1443866: email 3.0+ stops parsing headers prematurely
http://bugs.python.org/issue1443866  closed by r.david.murray

#1491804: Simple slice support for list.sort() and .reverse()
http://bugs.python.org/issue1491804  closed by rhettinger

#1158231: string.Template does not allow step-by-step replacements
http://bugs.python.org/issue1158231  closed by rhettinger

#1590352: The "lazy strings" patch
http://bugs.python.org/issue1590352  closed by eric.araujo

#477863: Print warning at shutdown if gc.garbage not empty
http://bugs.python.org/issue477863  closed by pitrou

#1095821: The doc for DictProxy is missing
http://bugs.python.org/issue1095821  closed by terry.reedy

#1744382: Read Write lock
http://bugs.python.org/issue1744382  closed by terry.reedy

#1707753: get status output fix for Win32
http://bugs.python.org/issue1707753  closed by tim.golden

#1498363: Improve super() objects support for implicit method calls
http://bugs.python.org/issue1498363  closed by rhettinger

#1566260: Better order in file type descriptions
http://bugs.python.org/issue1566260  closed by tim.golden

#1730480: dict init/update accesses internal items of dict derivative
http://bugs.python.org/issue1730480  closed by terry.reedy

#1306248: Add 64-bit Solaris 9 build instructions to README
http://bugs.python.org/issue1306248  closed by terry.reedy

#1173475: __slots__ for subclasses of variable length types
http://bugs.python.org/issue1173475  closed by rhettinger

#1714451: subprocess.py problems errors when calling cmd.exe
http://bugs.python.org/issue1714451  closed by tim.golden

From barry at python.org  Fri Aug 13 17:57:57 2010
From: barry at python.org (Barry Warsaw)
Date: Fri, 13 Aug 2010 11:57:57 -0400
Subject: [Python-Dev] Fixing #7175: a standard location for Python
 config files
In-Reply-To: <AANLkTim04GLfqfR0U8GzzzveKF9iWaGo7_vw9bvnz3Mk@mail.gmail.com>
References: <4C62C01D.6000900@netwok.org> <4C63C3F1.6000603@timgolden.me.uk>
	<i40hps$5r7$1@dough.gmane.org>
	<AANLkTim04GLfqfR0U8GzzzveKF9iWaGo7_vw9bvnz3Mk@mail.gmail.com>
Message-ID: <20100813115757.40100b29@heresy>

On Aug 12, 2010, at 09:10 AM, Fred Drake wrote:

>Perhaps user configuration belongs in ~/.local/, or ~/.local/python/
>(with attendant Windows & Mac OS noises); I don't really care where it
>lands, because right now we just have a mess.  Getting it "right" with
>respect to Window's "roaming" notion and how people expect to work
>with it is... unlikely.  Picking a place is better than not, so we
>know where to find things.  But that's all it buys us.

I've missed most of this discussion while on vacation, but if ~/.local is
supposed to mirror /usr/local, then wouldn't a logical place for per-user
configuration files be ~/.local/etc/whatever.cfg?

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100813/1575c921/attachment.pgp>

From esnow at verio.net  Fri Aug 13 18:49:43 2010
From: esnow at verio.net (Eric Snow)
Date: Fri, 13 Aug 2010 12:49:43 -0400
Subject: [Python-Dev] Proposed tweaks to functools.wraps
In-Reply-To: <AANLkTingvAu04vhTSQT8wrrw_q_Boa0b_m3iib-LSZKX@mail.gmail.com>
References: <AANLkTimQhkeUWHBLrsmW+JDOMimgjnpxihUh1L894Zoz@mail.gmail.com><D2F744D05ED19D45A4A7757F49274A8B03B95E67@IAD-WPRD-XCHB01.corp.verio.net>
	<AANLkTingvAu04vhTSQT8wrrw_q_Boa0b_m3iib-LSZKX@mail.gmail.com>
Message-ID: <D2F744D05ED19D45A4A7757F49274A8B03B95E86@IAD-WPRD-XCHB01.corp.verio.net>

True.  It is tricky.  However, not as tricky as finding the decorated function after the fact (unless I am missing something).  But maybe that is a fringe need (finding the original function).

-eric

-----Original Message-----
From: Nick Coghlan [mailto:ncoghlan at gmail.com] 
Sent: Friday, August 13, 2010 10:07 AM
To: Eric Snow
Cc: python-dev at python.org
Subject: Re: [Python-Dev] Proposed tweaks to functools.wraps

On Sat, Aug 14, 2010 at 1:01 AM, Eric Snow <esnow at verio.net> wrote:
> Actually, what is the problem with having all decorators add a __decorated__ to the function that ultimately gets returned, pointing to the function they decorated?  I guess I never saw that discussion.  Perhaps set it to None when the decorator is the same as the decorated (no wrapping involved).  The alternative is sifting through closures, trying to figure out which is the decorated function.  Finding the original decorated function has been a real pain, particularly when a function has more than one closure cell.

Because decorators don't always return simple wrapper functions -
sometimes they return the original function and sometimes they
completely replace the original function with something else entirely
(which may not be callable, or even mutable). We refused the
temptation to try to guess when it was appropriate to add the
referring attribute.

functools.update_wrapper and functools.wraps are explicit though, so
it's easy to add the attribute there, we just hadn't thought of doing
it before now.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia


This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free.  Thank you.

From fdrake at acm.org  Fri Aug 13 20:16:03 2010
From: fdrake at acm.org (Fred Drake)
Date: Fri, 13 Aug 2010 14:16:03 -0400
Subject: [Python-Dev] Fixing #7175: a standard location for Python
	config files
In-Reply-To: <20100813115757.40100b29@heresy>
References: <4C62C01D.6000900@netwok.org> <4C63C3F1.6000603@timgolden.me.uk>
	<i40hps$5r7$1@dough.gmane.org>
	<AANLkTim04GLfqfR0U8GzzzveKF9iWaGo7_vw9bvnz3Mk@mail.gmail.com>
	<20100813115757.40100b29@heresy>
Message-ID: <AANLkTinTjoG6GzTTVKzrboahrap5m5D+c-Lr8SyeD590@mail.gmail.com>

On Fri, Aug 13, 2010 at 11:57 AM, Barry Warsaw <barry at python.org> wrote:
> I've missed most of this discussion while on vacation, but if ~/.local is
> supposed to mirror /usr/local, then wouldn't a logical place for per-user
> configuration files be ~/.local/etc/whatever.cfg?

Maybe it is; I'd hope so.

The fd.o spec that describes ~/.local/share/ doesn't say anything
*else* about ~/.local/, though.  So our expansion of ~/.local/ is very
much our own.

My own ~/.local/ contains a bunch of gnomish desktop stuff in share/
and Python stuff in lib/, and that's it.

I'd be as happy as I'm going to be with configs in ~~/.local/etc/.
(Still going to be a grouchy old fart.)


? -Fred

--
Fred L. Drake, Jr.? ? <fdrake at gmail.com>
"A storm broke loose in my mind."? --Albert Einstein

From solipsis at pitrou.net  Fri Aug 13 20:28:31 2010
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Fri, 13 Aug 2010 20:28:31 +0200
Subject: [Python-Dev] Fixing #7175: a standard location for Python
	config files
References: <4C62C01D.6000900@netwok.org> <4C63C3F1.6000603@timgolden.me.uk>
	<i40hps$5r7$1@dough.gmane.org>
	<AANLkTim04GLfqfR0U8GzzzveKF9iWaGo7_vw9bvnz3Mk@mail.gmail.com>
	<20100813115757.40100b29@heresy>
Message-ID: <20100813202831.351c6975@pitrou.net>

On Fri, 13 Aug 2010 11:57:57 -0400
Barry Warsaw <barry at python.org> wrote:

> On Aug 12, 2010, at 09:10 AM, Fred Drake wrote:
> 
> >Perhaps user configuration belongs in ~/.local/, or ~/.local/python/
> >(with attendant Windows & Mac OS noises); I don't really care where it
> >lands, because right now we just have a mess.  Getting it "right" with
> >respect to Window's "roaming" notion and how people expect to work
> >with it is... unlikely.  Picking a place is better than not, so we
> >know where to find things.  But that's all it buys us.
> 
> I've missed most of this discussion while on vacation, but if ~/.local is
> supposed to mirror /usr/local, then wouldn't a logical place for per-user
> configuration files be ~/.local/etc/whatever.cfg?

I think this has already been debated, -1 on it.

Antoine.



From sturla at molden.no  Fri Aug 13 20:45:25 2010
From: sturla at molden.no (Sturla Molden)
Date: Fri, 13 Aug 2010 20:45:25 +0200
Subject: [Python-Dev] mingw support?
In-Reply-To: <4C6508DD.7080503@v.loewis.de>
References: <20100807195541.GA13990@laptop.gs> <i3n225$osp$1@dough.gmane.org>
	<AANLkTi=dc=0brYo34=xaU6D9wH97eB_tTN=b=FBNjLNh@mail.gmail.com>
	<9f2ea5ad00140f45fdf639eb0b234aea.squirrel@webmail.uio.no>
	<i3q110$ncr$1@dough.gmane.org> <20100810140620.GB4464@laptop.gs>
	<AANLkTik0QoHNXGgqhbtQKJqrFoC3kxzzomm06sJfZLJ8@mail.gmail.com>
	<40b838e9eeeac1852e96a0f5d25d67a0.squirrel@webmail.uio.no>
	<AANLkTimfAiHnLkq_6-uU=Xd-2+bZdHa8qn-4kLazbwS6@mail.gmail.com>
	<20100812150011.GA11541@laptop.gs>
	<AANLkTikaafnJJBgiYfJf+v1B21RizYSjEzMBKRkBdLVL@mail.gmail.com>
	<4C64874C.6040206@canterbury.ac.nz> <4C6485AF.1020704@voidspace.org.uk>
	<87y6cbm6fk.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4C6508DD.7080503@v.loewis.de>
Message-ID: <c5a82e89e1fcef9061dda10c9de7afc0.squirrel@webmail.uio.no>


> The problem really is that when people ask for MingW support, they mean
> all kinds of things,

Usually it means they want to build C or C++ extensions, don't have Visual
Studio, don't know about the SDK compiler, and have misunderstood the CRT
problem.

As long at Python builds with the free Windows 7 SDK, I think it is
sufficient to that mingw is supported for extensions (and the only reasons
for selecing mingw over Microsoft C/C++ on windows are Fortran and C99 --
the Windows SDK compiler is a free download as well.)

Enthought (32-bit) ships with a mingw gcc compiler configured to build
extensions. That might be something to consider for Python on Windows. It
will prevent accidental linking with wrong libraries (particularly the
CRT).

Sturla






From sturla at molden.no  Fri Aug 13 21:04:30 2010
From: sturla at molden.no (Sturla Molden)
Date: Fri, 13 Aug 2010 21:04:30 +0200
Subject: [Python-Dev] mingw support?
In-Reply-To: <AANLkTinMJbwyVoX1VYue3bxjqmh_xbXdZDHTkgXjHma1@mail.gmail.com>
References: <20100807195541.GA13990@laptop.gs> <i3n225$osp$1@dough.gmane.org>
	<AANLkTi=dc=0brYo34=xaU6D9wH97eB_tTN=b=FBNjLNh@mail.gmail.com>
	<9f2ea5ad00140f45fdf639eb0b234aea.squirrel@webmail.uio.no>
	<i3q110$ncr$1@dough.gmane.org> <20100810140620.GB4464@laptop.gs>
	<AANLkTik0QoHNXGgqhbtQKJqrFoC3kxzzomm06sJfZLJ8@mail.gmail.com>
	<40b838e9eeeac1852e96a0f5d25d67a0.squirrel@webmail.uio.no>
	<AANLkTimfAiHnLkq_6-uU=Xd-2+bZdHa8qn-4kLazbwS6@mail.gmail.com>
	<20100812150011.GA11541@laptop.gs>
	<AANLkTikaafnJJBgiYfJf+v1B21RizYSjEzMBKRkBdLVL@mail.gmail.com>
	<4C64874C.6040206@canterbury.ac.nz>
	<AANLkTinMJbwyVoX1VYue3bxjqmh_xbXdZDHTkgXjHma1@mail.gmail.com>
Message-ID: <e8354bda252b3fb170810a1ff941e932.squirrel@webmail.uio.no>

"Cesare Di Mauro":

> I like to use Windows because it's a comfortable and productive
> environment,
> certainly not because someone forced me to use it.
>
> Also, I have limited time, so I want to spend it the better I can,
> focusing
> on solving real problems. Setup, Next, Next, Finish, and I want it working
> without thinking about anything else.
[...]
> Give users a better choice, and I don't see logical reasons because
> they'll
> not change their mind.


I use Windows too, even though I am a scientist and most people seem to
prefer Linux for scientific computing. I do like to just click on the
installer from Enthought and forget about building all the binaries an
libraries myself. Maybe I am just lazy...

But likewise, I think that most Windows users don't care which C compiler
was used to build Python. Nor do we/they care which compiler was used to
build any other third-party software, as long as the MSI installers works
and the binaries are void of malware.

Also note that there are non-standard things on Windows that mingw does
not support properly, such as COM and structured exceptions. Extensions
like pywin32 depend on Microsoft C/C++ for that reason.

So for Windows I think it is sufficient to support mingw for extension
libraries. The annoying part is the CRT DLL hell, which is the fault of
Microsoft. An easy fix would be a Python/mingw bundle, or a correctly
configured mingw compiler from python.org. Or Python devs could consider
not using Microsoft's CRT at all on Windows, and replacing it with a
custom CRT or plain Windows API calls.

Sturla










From john at arbash-meinel.com  Fri Aug 13 21:21:45 2010
From: john at arbash-meinel.com (John Arbash Meinel)
Date: Fri, 13 Aug 2010 14:21:45 -0500
Subject: [Python-Dev] Fixing #7175: a standard location for Python
 config files
In-Reply-To: <20100813020037.GA3328@aihal.home.puzzling.org>
References: <4C62C01D.6000900@netwok.org>
	<4C63C3F1.6000603@timgolden.me.uk>	<i40hps$5r7$1@dough.gmane.org>
	<4C63CD36.4050400@timgolden.me.uk>	<A01493B1-61C5-41B8-B673-31A3993FE760@twistedmatrix.com>	<20100813002959.4b455cd8@pitrou.net>
	<20100813020037.GA3328@aihal.home.puzzling.org>
Message-ID: <4C659B49.3090500@arbash-meinel.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


...
>  * that said, Windows seems much slower than Linux on equivalent
>    hardware, perhaps attempting to open files is intrinsically more
>    expensive there?  Certainly it's not safe to assume conclusions drawn
>    on Linux will apply equally well on Windows, or vice versa.

I don't know what the specific issue is here, but adding entries to
sys.path makes startup time *significantly* slower.

I happen to use easy_install since Windows doesn't have its own package
manager. Unfortunately the default of creating a new directory and
adding it to easy_install.pth is actually pretty terrible.

On my system, 'len(sys.path)' is 72 entries long. 62 of that is from
easy-install. A huge amount of that is all the zope and lazr.
dependencies that are needed by launchpadlib (not required for bzr itself.)

With a fully hot cache, and running the minimal bzr command:

 time bzr rocks --no-plugins
 real 0m0.395s
vs
 real 0m0.195s

So about 400ms to startup versus 200ms if I use the packaged version of
bzr (which has a very small search path).

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkxlm0kACgkQJdeBCYSNAAMSEgCfW24XNG3h20UkFdEODNMob6uR
nisAoLes/usoHd1YRDIkzxfIJohPjSer
=YO9b
-----END PGP SIGNATURE-----

From barry at python.org  Fri Aug 13 21:29:14 2010
From: barry at python.org (Barry Warsaw)
Date: Fri, 13 Aug 2010 15:29:14 -0400
Subject: [Python-Dev] Python 2.6.6 status
Message-ID: <20100813152914.424083c7@heresy>

Hi folks,

I'm liking where we're at for Python 2.6.6.  We have no release blocker issues
open, and the buildbots look about as green as they get.  I've accounted for
all the commits since 2.6.6rc1 and I think barring any last minute issues,
that we're on schedule for 2.6.6 final for this Monday, August 16.

Please, no commits to release26-maint without checking with me first (svnmerge
blocks are okay).  I plan to tag the release at approximately 2200 UTC Monday
so that Martin can build the Windows binaries first thing on Tuesday and I can
announce the release Tuesday afternoon EST.

I'll be hanging out on #python-dev as much as possible over the weekend in
case anything crops up.

Thanks to everybody who has helped get 2.6.6 to such an awesome state.

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100813/686a6f7b/attachment.pgp>

From fdrake at acm.org  Fri Aug 13 21:32:53 2010
From: fdrake at acm.org (Fred Drake)
Date: Fri, 13 Aug 2010 15:32:53 -0400
Subject: [Python-Dev] Fixing #7175: a standard location for Python
	config files
In-Reply-To: <4C659B49.3090500@arbash-meinel.com>
References: <4C62C01D.6000900@netwok.org> <4C63C3F1.6000603@timgolden.me.uk>
	<i40hps$5r7$1@dough.gmane.org> <4C63CD36.4050400@timgolden.me.uk>
	<A01493B1-61C5-41B8-B673-31A3993FE760@twistedmatrix.com>
	<20100813002959.4b455cd8@pitrou.net>
	<20100813020037.GA3328@aihal.home.puzzling.org>
	<4C659B49.3090500@arbash-meinel.com>
Message-ID: <AANLkTi=NHT6ZePOCLkXMuidu04_v2j87DhwarSkxB9_x@mail.gmail.com>

On Fri, Aug 13, 2010 at 3:21 PM, John Arbash Meinel
<john at arbash-meinel.com> wrote:
> I don't know what the specific issue is here, but adding entries to
> sys.path makes startup time *significantly* slower.
>
> I happen to use easy_install since Windows doesn't have its own package
> manager. Unfortunately the default of creating a new directory and
> adding it to easy_install.pth is actually pretty terrible.

Adding sys.path entries on Linux isn't free either.

Fortunately, this isn't about adding anything to sys.path.


? -Fred

--
Fred L. Drake, Jr.? ? <fdrake at gmail.com>
"A storm broke loose in my mind."? --Albert Einstein

From fuzzyman at voidspace.org.uk  Fri Aug 13 23:02:45 2010
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Fri, 13 Aug 2010 22:02:45 +0100
Subject: [Python-Dev] Fixing #7175: a standard location for
 Python	config files
In-Reply-To: <87wrrvm5qe.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <4C62C01D.6000900@netwok.org>	<4C63C3F1.6000603@timgolden.me.uk>	<i40hps$5r7$1@dough.gmane.org>	<4C63CF8E.1090308@voidspace.org.uk>	<4C63D2E5.80606@timgolden.me.uk>	<4C63D85D.1020409@voidspace.org.uk>
	<87wrrvm5qe.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <4C65B2F5.20807@voidspace.org.uk>

On 13/08/2010 06:39, Stephen J. Turnbull wrote:
> Michael Foord writes:
>
>   >  How is ~/python not memorable or consistent? (And cross-platform
>   >  memorability and consistency is valuable too.)
>
> But what does "~" mean on Windows?
There is a "user directory" in Windows directly analagous to ~, and this 
is the path returned by os.path.expanduser('~') in Python:

 >>> import os
 >>> os.path.expanduser('~')
'C:\\Users\\michael'

(Windows 7)

> Inside of Python you can have a
> consistent definition, but that doesn't help people whose installer
> gets mixed signals so Python itself is in the wrong place, or who are
> using external tools (uninstaller, editor, application, etc) that work
> on or with Python.
>
> I'm not arguing for use of AppData, but at least it's easy to explain,
> and easy to implement, for consistency.
>
>    

Likewise with the user directory (IMO) - in fact to explain where 
AppData is to a Windows user you first explain about the user directory 
(AppData is under the user directory).

Personally I would like to see the defaults being:

Linux: ~/.pythonx.y
Mac OS X: ~/.pythonx.y with a fallback of ~/Library/Preferences/.pythonx.y
Windows: ~/pythonx.y perhaps with a backup of AppData/pythonx.y

For both Windows and Mac OS X I would be happy with the fallback / 
primary to be the other way round - it doesn't *really* matter. The API 
for getting the user config direction should always return a list I 
guess if we have fallbacks.

Someone else in this thread (Adal Chiriliuc) expressed a preferences for 
the documents folder on Windows over the home directory. This would be 
fine as well (with AppData still as a fallback). This is used by other 
native windows applications. (In earlier versions of Windows the 
documents folder was explicitly called "Documents and Settings".)

We should use pythonx.y rather than just python because (for example) 
you will typically have different packages installed when you have 
multiple versions of Python, and in unittest would then want / need 
different plugins enabled and configured in the unittest config files 
for each of the versions of Python.

I've added this text to the issue and Tarek - as bdfl for distutils2 
should just make a decision (and the rest of us will have to live with 
it). :-)
>   >  Another issue is discoverability. Many users won't know about these
>   >  config files unless they *see* them.
>
> OK, maybe AppData's out.
>
>   >  In fact for Windows the *correct* thing to do is probably to use
>   >  the registry and then provide a graphical tool for editing the
>   >  values. If you're arguing for consistency why not argue for this?
>
> Sounds reasonable to me.  Except Python's standard GUI is probably not
> up to Windows standards of beauty....
>
>    

Heh, I was actually being slightly sarcastic - just pointing out that if 
we are going to argue that we should do the "correct" thing for the 
platform that means the registry on Windows and plists on Mac OS X, with 
GUI apps to control them. That is an unnecessary burden for the standard 
library and actively makes them harder for developers to maintain 
themselves.

All the best,

Michael Foord

-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (?BOGUS AGREEMENTS?) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.



From mail at timgolden.me.uk  Fri Aug 13 23:15:21 2010
From: mail at timgolden.me.uk (Tim Golden)
Date: Fri, 13 Aug 2010 22:15:21 +0100
Subject: [Python-Dev] Fixing #7175: a standard location for
 Python	config files
In-Reply-To: <4C65B2F5.20807@voidspace.org.uk>
References: <4C62C01D.6000900@netwok.org>	<4C63C3F1.6000603@timgolden.me.uk>	<i40hps$5r7$1@dough.gmane.org>	<4C63CF8E.1090308@voidspace.org.uk>	<4C63D2E5.80606@timgolden.me.uk>	<4C63D85D.1020409@voidspace.org.uk>
	<87wrrvm5qe.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4C65B2F5.20807@voidspace.org.uk>
Message-ID: <4C65B5E9.1000205@timgolden.me.uk>

On 13/08/2010 10:02 PM, Michael Foord wrote:
> On 13/08/2010 06:39, Stephen J. Turnbull wrote:
>> Michael Foord writes:
>>
>>    >   How is ~/python not memorable or consistent? (And cross-platform
>>    >   memorability and consistency is valuable too.)
>>
>> But what does "~" mean on Windows?
> There is a "user directory" in Windows directly analagous to ~, and this
> is the path returned by os.path.expanduser('~') in Python:

Well, see my post early on in the thread about the
various senses of "user directory" under Windows.
The addition of expanduser to include Windows caused
a long debate at the time.  (ISTR)

I'm not really all that bothered for this purpose.
There's something to be said for all the suggestions
so far. However, as I've said elsewhere, I'm more
concerned that whatever we end up choosing for
location(s) be clearly documented as such.

TJG

From martin at v.loewis.de  Fri Aug 13 23:22:43 2010
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 13 Aug 2010 23:22:43 +0200
Subject: [Python-Dev] mingw support?
In-Reply-To: <c5a82e89e1fcef9061dda10c9de7afc0.squirrel@webmail.uio.no>
References: <20100807195541.GA13990@laptop.gs>
	<i3n225$osp$1@dough.gmane.org>	<AANLkTi=dc=0brYo34=xaU6D9wH97eB_tTN=b=FBNjLNh@mail.gmail.com>	<9f2ea5ad00140f45fdf639eb0b234aea.squirrel@webmail.uio.no>	<i3q110$ncr$1@dough.gmane.org>
	<20100810140620.GB4464@laptop.gs>	<AANLkTik0QoHNXGgqhbtQKJqrFoC3kxzzomm06sJfZLJ8@mail.gmail.com>	<40b838e9eeeac1852e96a0f5d25d67a0.squirrel@webmail.uio.no>	<AANLkTimfAiHnLkq_6-uU=Xd-2+bZdHa8qn-4kLazbwS6@mail.gmail.com>	<20100812150011.GA11541@laptop.gs>	<AANLkTikaafnJJBgiYfJf+v1B21RizYSjEzMBKRkBdLVL@mail.gmail.com>	<4C64874C.6040206@canterbury.ac.nz>
	<4C6485AF.1020704@voidspace.org.uk>	<87y6cbm6fk.fsf@uwakimon.sk.tsukuba.ac.jp>	<4C6508DD.7080503@v.loewis.de>
	<c5a82e89e1fcef9061dda10c9de7afc0.squirrel@webmail.uio.no>
Message-ID: <4C65B7A3.10701@v.loewis.de>

Am 13.08.2010 20:45, schrieb Sturla Molden:
> 
>> The problem really is that when people ask for MingW support, they mean
>> all kinds of things,
> 
> Usually it means they want to build C or C++ extensions, don't have Visual
> Studio, don't know about the SDK compiler, and have misunderstood the CRT
> problem.

True. However, that should be working just fine, for many years. It just
becomes a hassle every time we switch VS versions, and mingw fails to
support the new CRT version. There is really nothing we can do about
that, other than asking people to complain to the mingw developers.

> As long at Python builds with the free Windows 7 SDK, I think it is
> sufficient to that mingw is supported for extensions (and the only reasons
> for selecing mingw over Microsoft C/C++ on windows are Fortran and C99 --
> the Windows SDK compiler is a free download as well.)

People keep disagreeing with that judgement, and keep contributing
patches that supposed make Python itself build with mingw.

> Enthought (32-bit) ships with a mingw gcc compiler configured to build
> extensions.

Hmm. Including a gcc seems like a lot of overhead, not at least for the
need to provide sources as well.

Regards,
Martin

From sturla at molden.no  Fri Aug 13 23:44:21 2010
From: sturla at molden.no (Sturla Molden)
Date: Fri, 13 Aug 2010 23:44:21 +0200
Subject: [Python-Dev] mingw support?
In-Reply-To: <4C65B7A3.10701@v.loewis.de>
References: <20100807195541.GA13990@laptop.gs> <i3n225$osp$1@dough.gmane.org>
	<AANLkTi=dc=0brYo34=xaU6D9wH97eB_tTN=b=FBNjLNh@mail.gmail.com>
	<9f2ea5ad00140f45fdf639eb0b234aea.squirrel@webmail.uio.no>
	<i3q110$ncr$1@dough.gmane.org> <20100810140620.GB4464@laptop.gs>
	<AANLkTik0QoHNXGgqhbtQKJqrFoC3kxzzomm06sJfZLJ8@mail.gmail.com>
	<40b838e9eeeac1852e96a0f5d25d67a0.squirrel@webmail.uio.no>
	<AANLkTimfAiHnLkq_6-uU=Xd-2+bZdHa8qn-4kLazbwS6@mail.gmail.com>
	<20100812150011.GA11541@laptop.gs>
	<AANLkTikaafnJJBgiYfJf+v1B21RizYSjEzMBKRkBdLVL@mail.gmail.com>
	<4C64874C.6040206@canterbury.ac.nz> <4C6485AF.1020704@voidspace.org.uk>
	<87y6cbm6fk.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4C6508DD.7080503@v.loewis.de>
	<c5a82e89e1fcef9061dda10c9de7afc0.squirrel@webmail.uio.no>
	<4C65B7A3.10701@v.loewis.de>
Message-ID: <e4da359555572ac693e2970a289c3a44.squirrel@webmail.uio.no>


>> Enthought (32-bit) ships with a mingw gcc compiler configured to build
>> extensions.
>
> Hmm. Including a gcc seems like a lot of overhead, not at least for the
> need to provide sources as well.

A lighter solution would be to include an importlib for the correct CRT as
well as for Python, and make sure distutils link with both for mingw. For
example we cannot use mingw for 64 bit extensions to Python 2.6 because
libpython26.a is missing from Python and mingw-w64 don't have
libmsvcr90.a. If Python shipped with both, there would not be a missing
import library for the CRT and no confusion as to which CRT to link.

For Python 2.5 there also was a CRT licensing issue for py2exe, but that
disappaired when MS provided download links for the Visual Studio
redistributables. I think this also contributed to a motivation for a
plain mingw build of Python 2.5, as it would take the CRT licensing issue
away from py2exe. But as of Python 2.6 this is not a problem anymore. Now
it is sufficient to direct the user to Microsoft's free CRT download.
Everybody might not be aware of that.

Sturla


From adijbr at gmail.com  Fri Aug 13 23:49:30 2010
From: adijbr at gmail.com (Alcino Dall'Igna Jr)
Date: Fri, 13 Aug 2010 18:49:30 -0300
Subject: [Python-Dev] i18n
Message-ID: <AANLkTinv=a8f3kO56CJ3FUgSZPh23fuSs7zyaofj=GMM@mail.gmail.com>

Dear developers:

I'm starting a project that aims at first to internationalize the python
interpreter, so it could be localized. I want to know if this could be
considered for the main trunk of python.

As a second phase I intend to internationalize the language itself so it
could be localized and used with kids and for programming teaching.

Finally a translator to give support for international collaboration in
education of youngsters.

I would like to hear of anyone interested in this.

Thanks in advance,

Alcino Dall Igna Junior
Lecturer at IC/UFAL - Brasil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100813/654eb670/attachment.html>

From barry at python.org  Sat Aug 14 04:43:38 2010
From: barry at python.org (Barry Warsaw)
Date: Fri, 13 Aug 2010 22:43:38 -0400
Subject: [Python-Dev] [Python-checkins] r83992 - in
 python/branches/release26-maint: Lib/distutils/command/sdist.py
 Lib/distutils/tests/test_sdist.py Misc/NEWS
In-Reply-To: <20100814020726.BD5CBF4AB@mail.python.org>
References: <20100814020726.BD5CBF4AB@mail.python.org>
Message-ID: <20100813224338.61d8aa76@heresy>

On Aug 14, 2010, at 04:07 AM, eric.araujo wrote:

>Author: eric.araujo
>Date: Sat Aug 14 04:07:26 2010
>New Revision: 83992
>
>Log:
>Revert regression from r81256 (with release manager approval, see
>#8688)

This was a regression in 2.6.6rc1 and I'm grateful to Eric for reverting it.
While I trust he did the merge faithfully, it's still a big enough change
between rc1 and final that I encourage folks who are affected by this to test
current svn head for release26-maint and make sure it's working the way you
expect it to.  This means "the same as Python 2.6.5".  We've decided not to
apply any behavior changing patches to Python 2.6 so you'll just have to live
with the devil you know here, or upgrade to Python 2.7.

Please let me know before Monday if you notice any problems.

Again, thanks Eric!
-Barry

>
>
>Modified:
>   python/branches/release26-maint/Lib/distutils/command/sdist.py
>   python/branches/release26-maint/Lib/distutils/tests/test_sdist.py
>   python/branches/release26-maint/Misc/NEWS
>
>Modified:
>python/branches/release26-maint/Lib/distutils/command/sdist.py
>==============================================================================
>---
>python/branches/release26-maint/Lib/distutils/command/sdist.py
>(original) +++
>python/branches/release26-maint/Lib/distutils/command/sdist.py
>Sat Aug 14 04:07:26 2010 @@ -57,8 +57,7 @@
>          "just regenerate the manifest and then stop "
>          "(implies --force-manifest)"),
>         ('force-manifest', 'f',
>-         "forcibly regenerate the manifest and carry on as usual. "
>-         "Deprecated: now the manifest is always regenerated."),
>+         "forcibly regenerate the manifest and carry on as usual"),
>         ('formats=', None,
>          "formats for source distribution (comma-separated list)"),
>         ('keep-temp', 'k',
>@@ -191,34 +190,67 @@
>         distribution, and put it in 'self.filelist'.  This might
> involve reading the manifest template (and writing the manifest), or
> just reading the manifest, or just using the default file set -- it
> all
>-        depends on the user's options.
>+        depends on the user's options and the state of the filesystem.
>         """
>-        # new behavior:
>-        # the file list is recalculated everytime because
>-        # even if MANIFEST.in or setup.py are not changed
>-        # the user might have added some files in the tree that
>-        # need to be included.
>-        #
>-        #  This makes --force the default and only behavior.
>-        template_exists = os.path.isfile(self.template)
>-        if not template_exists:
>-            self.warn(("manifest template '%s' does not exist " +
>-                        "(using default file list)") %
>-                        self.template)
>-        self.filelist.findall()
>-
>-        if self.use_defaults:
>-            self.add_defaults()
> 
>+        # If we have a manifest template, see if it's newer than the
>+        # manifest; if so, we'll regenerate the manifest.
>+        template_exists = os.path.isfile(self.template)
>         if template_exists:
>-            self.read_template()
>+            template_newer = dep_util.newer(self.template,
>self.manifest)
> 
>-        if self.prune:
>-            self.prune_file_list()
>+        # The contents of the manifest file almost certainly depend
>on the
>+        # setup script as well as the manifest template -- so if the
>setup
>+        # script is newer than the manifest, we'll regenerate the
>manifest
>+        # from the template.  (Well, not quite: if we already have a
>+        # manifest, but there's no template -- which will happen if
>the
>+        # developer elects to generate a manifest some other way --
>then we
>+        # can't regenerate the manifest, so we don't.)
>+        self.debug_print("checking if %s newer than %s" %
>+                         (self.distribution.script_name,
>self.manifest))
>+        setup_newer = dep_util.newer(self.distribution.script_name,
>+                                     self.manifest)
>+
>+        # cases:
>+        #   1) no manifest, template exists: generate manifest
>+        #      (covered by 2a: no manifest == template newer)
>+        #   2) manifest & template exist:
>+        #      2a) template or setup script newer than manifest:
>+        #          regenerate manifest
>+        #      2b) manifest newer than both:
>+        #          do nothing (unless --force or --manifest-only)
>+        #   3) manifest exists, no template:
>+        #      do nothing (unless --force or --manifest-only)
>+        #   4) no manifest, no template: generate w/ warning
>("defaults only") +
>+        manifest_outofdate = (template_exists and
>+                              (template_newer or setup_newer))
>+        force_regen = self.force_manifest or self.manifest_only
>+        manifest_exists = os.path.isfile(self.manifest)
>+        neither_exists = (not template_exists and not manifest_exists)
>+
>+        # Regenerate the manifest if necessary (or if explicitly told
>to)
>+        if manifest_outofdate or neither_exists or force_regen:
>+            if not template_exists:
>+                self.warn(("manifest template '%s' does not exist " +
>+                           "(using default file list)") %
>+                          self.template)
>+            self.filelist.findall()
>+
>+            if self.use_defaults:
>+                self.add_defaults()
>+            if template_exists:
>+                self.read_template()
>+            if self.prune:
>+                self.prune_file_list()
>+
>+            self.filelist.sort()
>+            self.filelist.remove_duplicates()
>+            self.write_manifest()
> 
>-        self.filelist.sort()
>-        self.filelist.remove_duplicates()
>-        self.write_manifest()
>+        # Don't regenerate the manifest, just read it in.
>+        else:
>+            self.read_manifest()
> 
>     # get_file_list ()
> 
>
>Modified:
>python/branches/release26-maint/Lib/distutils/tests/test_sdist.py
>==============================================================================
>---
>python/branches/release26-maint/Lib/distutils/tests/test_sdist.py
>(original) +++
>python/branches/release26-maint/Lib/distutils/tests/test_sdist.py
>Sat Aug 14 04:07:26 2010 @@ -29,7 +29,6 @@
>         super(sdistTestCase, self).setUp()
>         self.old_path = os.getcwd()
>         self.temp_pkg = os.path.join(self.mkdtemp(), 'temppkg')
>-        self.tmp_dir = self.mkdtemp()
> 
>     def tearDown(self):
>         os.chdir(self.old_path)
>@@ -152,67 +151,6 @@
>         self.assertEquals(result,
>                 ['fake-1.0.tar', 'fake-1.0.tar.gz'])
> 
>-    def get_cmd(self, metadata=None):
>-        """Returns a cmd"""
>-        if metadata is None:
>-            metadata = {'name': 'fake', 'version': '1.0',
>-                        'url': 'xxx', 'author': 'xxx',
>-                        'author_email': 'xxx'}
>-        dist = Distribution(metadata)
>-        dist.script_name = 'setup.py'
>-        dist.packages = ['somecode']
>-        dist.include_package_data = True
>-        cmd = sdist(dist)
>-        cmd.dist_dir = 'dist'
>-        def _warn(*args):
>-            pass
>-        cmd.warn = _warn
>-        return dist, cmd
>-
>-    def test_get_file_list(self):
>-        # make sure MANIFEST is recalculated
>-        dist, cmd = self.get_cmd()
>-
>-        os.chdir(self.tmp_dir)
>-
>-        # filling data_files by pointing files in package_data
>-        os.mkdir(os.path.join(self.tmp_dir, 'somecode'))
>-        self.write_file((self.tmp_dir, 'somecode', '__init__.py'),
>'#')
>-        self.write_file((self.tmp_dir, 'somecode', 'one.py'), '#')
>-        cmd.ensure_finalized()
>-        cmd.run()
>-
>-        f = open(cmd.manifest)
>-        try:
>-            manifest = [line.strip() for line in f.read().split('\n')
>-                        if line.strip() != '']
>-        finally:
>-            f.close()
>-
>-        self.assertEquals(len(manifest), 2)
>-
>-        # adding a file
>-        self.write_file((self.tmp_dir, 'somecode', 'two.py'), '#')
>-
>-        # make sure build_py is reinitinialized, like a fresh run
>-        build_py = dist.get_command_obj('build_py')
>-        build_py.finalized = False
>-        build_py.ensure_finalized()
>-
>-        cmd.run()
>-
>-        f = open(cmd.manifest)
>-        try:
>-            manifest2 = [line.strip() for line in f.read().split('\n')
>-                         if line.strip() != '']
>-        finally:
>-            f.close()
>-
>-        # do we have the new file in MANIFEST ?
>-        self.assertEquals(len(manifest2), 3)
>-        self.assert_('two.py' in manifest2[-1])
>-
>-
> def test_suite():
>     return unittest.makeSuite(sdistTestCase)
> 
>
>Modified: python/branches/release26-maint/Misc/NEWS
>==============================================================================
>--- python/branches/release26-maint/Misc/NEWS	(original)
>+++ python/branches/release26-maint/Misc/NEWS	Sat Aug 14
>04:07:26 2010 @@ -12,6 +12,9 @@
> Library
> -------
> 
>+- Issue #8688: Revert regression introduced in 2.6.6rc1 (making
>Distutils
>+  recalculate MANIFEST every time).
>+
> - Issue #5798: Handle select.poll flag oddities properly on OS X.
>   This fixes test_asynchat and test_smtplib failures on OS X.
> 
>_______________________________________________
>Python-checkins mailing list
>Python-checkins at python.org
>http://mail.python.org/mailman/listinfo/python-checkins
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100813/53d42647/attachment-0001.pgp>

From zooko at zooko.com  Sat Aug 14 08:35:07 2010
From: zooko at zooko.com (Zooko O'Whielacronx)
Date: Sat, 14 Aug 2010 00:35:07 -0600
Subject: [Python-Dev] mingw support?
In-Reply-To: <i3keql$fsu$1@dough.gmane.org>
References: <20100807195541.GA13990@laptop.gs> <i3keql$fsu$1@dough.gmane.org>
Message-ID: <AANLkTinNUfs70iKBgW=OousBSBwu=eGCRqUjATU+gaUZ@mail.gmail.com>

On Sat, Aug 7, 2010 at 2:14 PM, Steve Holden <steve at holdenweb.com> wrote:
> There have certainly been demonstrations that Python can be compiled
> with mingw, but as far as I am aware what's ?missing is a developer
> sufficiently motivated to integrate that build system into the
> distributions and maintain it.

It looks like quite a lot of activity on
http://bugs.python.org/issue3871 . I find it surprising that nobody
mentioned it before on this thread. Perhaps nobody who has been
posting to this thread was aware of this activity.

Regards,

Zooko

From asmodai at in-nomine.org  Sat Aug 14 10:18:16 2010
From: asmodai at in-nomine.org (Jeroen Ruigrok van der Werven)
Date: Sat, 14 Aug 2010 10:18:16 +0200
Subject: [Python-Dev] i18n
In-Reply-To: <AANLkTinv=a8f3kO56CJ3FUgSZPh23fuSs7zyaofj=GMM@mail.gmail.com>
References: <AANLkTinv=a8f3kO56CJ3FUgSZPh23fuSs7zyaofj=GMM@mail.gmail.com>
Message-ID: <20100814081816.GC49566@nexus.in-nomine.org>

-On [20100813 23:51], Alcino Dall'Igna Jr (adijbr at gmail.com) wrote:
>I'm starting a project that aims at first to?internationalize?the python
>interpreter, so it could be localized. I want to know if this could be
>considered for the main trunk of python.?

I doubt you will be able to localize much with regard to the interpreter.
The only thing that really comes to mind are the error and exception
messages, but you will never be able to localize the errors themselves. The
problem there is that if they seek help on international fora for Python,
other people might have no clue what the (error) message even means. The
only portable way around that is if you start assigning each and every
message in the interpreter an integer that's unique. That way one is always
able to identify across languages which exact message is being referred to.
I think AIX did something similar.

>As a second phase I intend to?internationalize the language itself so it could
>be localized and used with kids and for programming teaching.?

I think this is not going to be helpful in the long run. The upside is that
you are teaching programming in their native language. The more heavy
downside is that you are creating a programming dialect that requires
extensive rewriting (which might or might not be automated) in order to be
compatible with the Python the rest of the world uses. This is frustrating
for the budding programmer. Especially if they seek help using the various
help fora available to them.
Aside from that, the way Python is using English idiom in its syntax does
not necessarily mean you can translate it 1-on-1 to a target language.
If-then-else might become very convoluted in, say, Japanese. So what then
will the added benefit be for the main trunk of Python?

Personally I think it would be much more valuable if the Python
documentation had some volunteers working on it to get it translated to
their own language.

Just my EUR 0,05.

-- 
Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
????? ?????? ??? ?? ??????
http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B
Only a life lived for others is worth living...

From martin at v.loewis.de  Sat Aug 14 11:22:39 2010
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 14 Aug 2010 11:22:39 +0200
Subject: [Python-Dev] i18n
In-Reply-To: <AANLkTinv=a8f3kO56CJ3FUgSZPh23fuSs7zyaofj=GMM@mail.gmail.com>
References: <AANLkTinv=a8f3kO56CJ3FUgSZPh23fuSs7zyaofj=GMM@mail.gmail.com>
Message-ID: <4C66605F.3090301@v.loewis.de>

> I'm starting a project that aims at first to internationalize the python
> interpreter, so it could be localized. I want to know if this could be
> considered for the main trunk of python. 

It's not exactly clear what you are proposing, but most likely, the
answer is "no". If you plan to internationalize the keywords and the
names of the library functions, then this can never go into Python.

Translating the doc strings might be ok. However, instead of doing so,
I recommend that you join the project to translate the Python
documentation, at pootle.python.org. This will not only help children,
but any user of the language who isn't very good at the English
language.

Regards,
Martin


From martin at v.loewis.de  Sat Aug 14 11:58:31 2010
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Sat, 14 Aug 2010 11:58:31 +0200
Subject: [Python-Dev] mingw support?
In-Reply-To: <AANLkTinNUfs70iKBgW=OousBSBwu=eGCRqUjATU+gaUZ@mail.gmail.com>
References: <20100807195541.GA13990@laptop.gs> <i3keql$fsu$1@dough.gmane.org>
	<AANLkTinNUfs70iKBgW=OousBSBwu=eGCRqUjATU+gaUZ@mail.gmail.com>
Message-ID: <4C6668C7.2080802@v.loewis.de>

Am 14.08.2010 08:35, schrieb Zooko O'Whielacronx:
> On Sat, Aug 7, 2010 at 2:14 PM, Steve Holden <steve at holdenweb.com> wrote:
>> There have certainly been demonstrations that Python can be compiled
>> with mingw, but as far as I am aware what's  missing is a developer
>> sufficiently motivated to integrate that build system into the
>> distributions and maintain it.
> 
> It looks like quite a lot of activity on
> http://bugs.python.org/issue3871 . I find it surprising that nobody
> mentioned it before on this thread. Perhaps nobody who has been
> posting to this thread was aware of this activity.

Or one of these:

http://bugs.python.org/issue1412448
http://bugs.python.org/issue1597850
http://bugs.python.org/issue3754
http://bugs.python.org/issue5026
http://bugs.python.org/issue6335

Because there is so many of them, all different, I didn't want to pick
out any specific. Notice that #3871 is really two patch: the original
one (from Roumen), and the one by ??????, who basically hijacked the issue.

Regards,
Martin

From martin at v.loewis.de  Sun Aug 15 17:59:28 2010
From: martin at v.loewis.de (=?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 15 Aug 2010 17:59:28 +0200
Subject: [Python-Dev] Parallel build slave
Message-ID: <4C680EE0.9030808@v.loewis.de>

I have set up 4-CPU system as a build slave, and enabled parallel builds
on it; this means that the Makefile and the testsuite is run in
parallel. configure and setup.py remain sequential. You can watch its
waterfall at

http://tinyurl.com/39a8u8m

Notice that the 2.6 branch doesn't support the -j option to regrtest.

Regards,
Martin

From florent.xicluna at gmail.com  Mon Aug 16 09:55:05 2010
From: florent.xicluna at gmail.com (Florent Xicluna)
Date: Mon, 16 Aug 2010 09:55:05 +0200
Subject: [Python-Dev]  bbreport users - please upgrade
Message-ID: <AANLkTimcaYOL3UaB_oDaw4+dS61PewNMSiKKfH_6rGqJ@mail.gmail.com>

Hello,

Recently I fixed parsing issues for failures like "hung for 30 minutes",
where the last test was no longer detected, since r83543 (the regrtest
progress bar, issue #8560).

You need to update the script to see the change:
http://code.google.com/p/bbreport/

Limitations:
 - the cache will not be updated, but future builds should be parsed
correctly.
 - there's no documentation yet (except ./bbreport.py --help)

-- 
Florent Xicluna
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100816/b3137768/attachment.html>

From barry at python.org  Mon Aug 16 17:54:48 2010
From: barry at python.org (Barry Warsaw)
Date: Mon, 16 Aug 2010 11:54:48 -0400
Subject: [Python-Dev] time critical: issue 7902 and 2.6.6rc2
Message-ID: <20100816115448.17fa9172@heresy>

For 2.6.6rc1 a patch was committed that addressed bug 7902:

http://bugs.python.org/issue7902

http://svn.python.org/view?rev=81381&view=rev

While this fixes a legitimate bug in Python 2.6, it also changes existing
behavior in the 2.6 series.  As 2.6.6 is the last planned maintenance release,
I do not think we've had enough testing of this change and am not sure it
should stay in.

Note that we've already seen one fallout from this.  Issue 9600 was fixed post
rc1.  While its use of the syntax was incorrect, and the fix was easy and
legitimate, I wonder how many other cases in unknown third party code there
might be.  Antoine in IRC suggests it will be rare, and that the
multiprocessing case was probably due to an incomplete code reorganization.  I
agree, but still.

http://bugs.python.org/issue9600

Either way, I think we need a 2.6.6rc2 (a thought that's been invading my
dreams all weekend :).  This would push back 2.6.6 final to September 12 or
13.

I'd like your opinion on whether the fix for 7902 should stay in 2.6.6 or
not.  Please respond asap, since *if* we revert this, I want that to go into
2.6.6rc2, and I'd like to tag that release in about 6 hours or so.

Thanks,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100816/926aa923/attachment.pgp>

From guido at python.org  Mon Aug 16 18:56:05 2010
From: guido at python.org (Guido van Rossum)
Date: Mon, 16 Aug 2010 09:56:05 -0700
Subject: [Python-Dev] time critical: issue 7902 and 2.6.6rc2
In-Reply-To: <20100816115448.17fa9172@heresy>
References: <20100816115448.17fa9172@heresy>
Message-ID: <AANLkTinSO03WSV=zsk_=8AP3aV4TWwGO_kwn9aF_5kLX@mail.gmail.com>

Sounds to me like the fix is legit, and the bug it uncovered was a
real bug and should have been caught. There really is no justification
to consider it a feature -- the PEP is clear on that. So I think we
should keep the fix.

If it is a gray area, it is only gray because the implementation was
imperfect, not because one could argue about whether it should be a
feature. Anyone who wrote "from .os import walk" thinking it should
work did not understand relative imports at all. But more likely such
code only happened through some (semi-)automated editing and nobody
thought much about it at all, and they would have preferred for it to
fail in the first place. All in all it seems pretty clear.

--Guido

On Mon, Aug 16, 2010 at 8:54 AM, Barry Warsaw <barry at python.org> wrote:
> For 2.6.6rc1 a patch was committed that addressed bug 7902:
>
> http://bugs.python.org/issue7902
>
> http://svn.python.org/view?rev=81381&view=rev
>
> While this fixes a legitimate bug in Python 2.6, it also changes existing
> behavior in the 2.6 series. ?As 2.6.6 is the last planned maintenance release,
> I do not think we've had enough testing of this change and am not sure it
> should stay in.
>
> Note that we've already seen one fallout from this. ?Issue 9600 was fixed post
> rc1. ?While its use of the syntax was incorrect, and the fix was easy and
> legitimate, I wonder how many other cases in unknown third party code there
> might be. ?Antoine in IRC suggests it will be rare, and that the
> multiprocessing case was probably due to an incomplete code reorganization. ?I
> agree, but still.
>
> http://bugs.python.org/issue9600
>
> Either way, I think we need a 2.6.6rc2 (a thought that's been invading my
> dreams all weekend :). ?This would push back 2.6.6 final to September 12 or
> 13.
>
> I'd like your opinion on whether the fix for 7902 should stay in 2.6.6 or
> not. ?Please respond asap, since *if* we revert this, I want that to go into
> 2.6.6rc2, and I'd like to tag that release in about 6 hours or so.
>
> Thanks,
> -Barry
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org
>
>



-- 
--Guido van Rossum (python.org/~guido)

From barry at python.org  Mon Aug 16 21:15:26 2010
From: barry at python.org (Barry Warsaw)
Date: Mon, 16 Aug 2010 15:15:26 -0400
Subject: [Python-Dev] time critical: issue 7902 and 2.6.6rc2
In-Reply-To: <AANLkTinSO03WSV=zsk_=8AP3aV4TWwGO_kwn9aF_5kLX@mail.gmail.com>
References: <20100816115448.17fa9172@heresy>
	<AANLkTinSO03WSV=zsk_=8AP3aV4TWwGO_kwn9aF_5kLX@mail.gmail.com>
Message-ID: <20100816151526.68bebd8f@heresy>

On Aug 16, 2010, at 09:56 AM, Guido van Rossum wrote:

>Sounds to me like the fix is legit, and the bug it uncovered was a
>real bug and should have been caught. There really is no justification
>to consider it a feature -- the PEP is clear on that. So I think we
>should keep the fix.

Sounds good to me.  Thanks for weighing in.

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100816/a70798a7/attachment.pgp>

From barry at python.org  Mon Aug 16 23:25:13 2010
From: barry at python.org (Barry Warsaw)
Date: Mon, 16 Aug 2010 17:25:13 -0400
Subject: [Python-Dev] time critical: issue 7902 and 2.6.6rc2
In-Reply-To: <20100816115448.17fa9172@heresy>
References: <20100816115448.17fa9172@heresy>
Message-ID: <20100816172513.0d64e92f@heresy>

On Aug 16, 2010, at 11:54 AM, Barry Warsaw wrote:

>Either way, I think we need a 2.6.6rc2 (a thought that's been invading
>my dreams all weekend :).  This would push back 2.6.6 final to
>September 12 or 13.

Make that 2.6.6 final on August 24.

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100816/116f622d/attachment.pgp>

From ncoghlan at gmail.com  Tue Aug 17 01:45:46 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 17 Aug 2010 09:45:46 +1000
Subject: [Python-Dev] time critical: issue 7902 and 2.6.6rc2
In-Reply-To: <20100816151526.68bebd8f@heresy>
References: <20100816115448.17fa9172@heresy>
	<AANLkTinSO03WSV=zsk_=8AP3aV4TWwGO_kwn9aF_5kLX@mail.gmail.com>
	<20100816151526.68bebd8f@heresy>
Message-ID: <AANLkTin2LLsbJLdF87f4pJRE3WLXbTbgY4MhdLH37y0t@mail.gmail.com>

On Tue, Aug 17, 2010 at 5:15 AM, Barry Warsaw <barry at python.org> wrote:
> On Aug 16, 2010, at 09:56 AM, Guido van Rossum wrote:
>
>>Sounds to me like the fix is legit, and the bug it uncovered was a
>>real bug and should have been caught. There really is no justification
>>to consider it a feature -- the PEP is clear on that. So I think we
>>should keep the fix.
>
> Sounds good to me. ?Thanks for weighing in.

A bit late (since you already cut rc2), but the key point for me is
that code that is fixed to work correctly on 2.6.6 (where this bug has
been fixed) will still work on any 2.6.x release.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From barry at python.org  Tue Aug 17 02:01:55 2010
From: barry at python.org (Barry Warsaw)
Date: Mon, 16 Aug 2010 20:01:55 -0400
Subject: [Python-Dev] time critical: issue 7902 and 2.6.6rc2
In-Reply-To: <AANLkTin2LLsbJLdF87f4pJRE3WLXbTbgY4MhdLH37y0t@mail.gmail.com>
References: <20100816115448.17fa9172@heresy>
	<AANLkTinSO03WSV=zsk_=8AP3aV4TWwGO_kwn9aF_5kLX@mail.gmail.com>
	<20100816151526.68bebd8f@heresy>
	<AANLkTin2LLsbJLdF87f4pJRE3WLXbTbgY4MhdLH37y0t@mail.gmail.com>
Message-ID: <20100816200155.2a54edef@heresy>

On Aug 17, 2010, at 09:45 AM, Nick Coghlan wrote:

>A bit late (since you already cut rc2), but the key point for me is
>that code that is fixed to work correctly on 2.6.6 (where this bug has
>been fixed) will still work on any 2.6.x release.

Yep, thanks.
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100816/e9a0bf92/attachment.pgp>

From g.brandl at gmx.net  Tue Aug 17 05:28:57 2010
From: g.brandl at gmx.net (Georg Brandl)
Date: Tue, 17 Aug 2010 05:28:57 +0200
Subject: [Python-Dev] r84124 - in python/branches/py3k:
 Doc/library/abc.rst Lib/abc.py Lib/test/test_abc.py Misc/NEWS
In-Reply-To: <20100817005253.25085EE9BC@mail.python.org>
References: <20100817005253.25085EE9BC@mail.python.org>
Message-ID: <i4cvlq$mc1$1@dough.gmane.org>

Am 17.08.2010 02:52, schrieb benjamin.peterson:
> Author: benjamin.peterson
> Date: Tue Aug 17 02:52:52 2010
> New Revision: 84124
> 
> Log:
> add support for abstract class and static methods #5867
> 
> Modified:
>    python/branches/py3k/Doc/library/abc.rst
>    python/branches/py3k/Lib/abc.py
>    python/branches/py3k/Lib/test/test_abc.py
>    python/branches/py3k/Misc/NEWS
> 
> Modified: python/branches/py3k/Doc/library/abc.rst
> ==============================================================================
> --- python/branches/py3k/Doc/library/abc.rst	(original)
> +++ python/branches/py3k/Doc/library/abc.rst	Tue Aug 17 02:52:52 2010
> @@ -157,6 +157,32 @@
>        multiple-inheritance.
>  
>  
> +.. decorator:: abstractclassmethod(function)

versionadded?

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.


From ncoghlan at gmail.com  Tue Aug 17 07:08:31 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 17 Aug 2010 15:08:31 +1000
Subject: [Python-Dev] Dev FAQ update request for svnmerge
Message-ID: <AANLkTinsj65AAL-wYRMug3gH-=q7hCjr=92MkW_02vTk@mail.gmail.com>

Could someone who knows how it is currently set up suggest a
correction to the dev FAQ for svnmerge usage?

The text at http://www.python.org/dev/faq/#how-do-i-merge-between-branches
still describes the situation as it was before the trunk was closed to
new checkins.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From orsenthil at gmail.com  Tue Aug 17 07:45:04 2010
From: orsenthil at gmail.com (Senthil Kumaran)
Date: Tue, 17 Aug 2010 11:15:04 +0530
Subject: [Python-Dev] Dev FAQ update request for svnmerge
In-Reply-To: <AANLkTinsj65AAL-wYRMug3gH-=q7hCjr=92MkW_02vTk@mail.gmail.com>
References: <AANLkTinsj65AAL-wYRMug3gH-=q7hCjr=92MkW_02vTk@mail.gmail.com>
Message-ID: <20100817054503.GA14238@remy>

On Tue, Aug 17, 2010 at 03:08:31PM +1000, Nick Coghlan wrote:
> Could someone who knows how it is currently set up suggest a
> correction to the dev FAQ for svnmerge usage?


2.26   How do I merge between branches?

All development occurs under the py3k branch and bug fixes are expected to be
merged into two additional branches, which are release2x-maint and
release3x-maint.

Assuming a change is committed into py3k as revision 0001, you
merge into the release2x-maint by doing:

# In the release2x-maint branch checkout.
svnmerge.py merge -r 0001
svn commit -F svnmerge-commit-message.txt  # r0002

# In a release3x-maint checkout.
svnmerge.py merge -r 0001
svn commit -F svnmerge-commit-message.txt  # r0003


# Optional

In rare situations where you want to backport a security fix or a
documentation fix into release26-maint branch: 

#In the release26-maint checkout.

svnmerge merge -S /python/branches/release27-maint -r0002
svn commit -F svnmerge-commit-message.txt  # r0004



-- 
Senthil

It's multiple choice time...

	What is FORTRAN?

	a: Between thre and fiv tran.
	b: What two computers engage in before they interface.
	c: Ridiculous.

From kristjan at ccpgames.com  Tue Aug 17 11:22:15 2010
From: kristjan at ccpgames.com (=?iso-8859-1?Q?Kristj=E1n_Valur_J=F3nsson?=)
Date: Tue, 17 Aug 2010 09:22:15 +0000
Subject: [Python-Dev] cProfile and threads
Message-ID: <930F189C8A437347B80DF2C156F7EC7F0B8DEA10AB@exchis.ccp.ad.local>

Hello there.
I'd like to draw your attention to two feature requests / patches that I've subbmitted:
http://bugs.python.org/issue9609
http://bugs.python.org/issue9622

These patches are the result of work that we have done in profiling Stackless Python server applications at runtime, but they apply just as well to C Python.
The first patch makes _lsprof, the engine behind cProfile, multi-stack aware.  This allows the same cProfiler.Profile() instance to be active on multiple python threads and still meaningful information is gathered.
The second patch allows to set the trace/profile function in python globally, so that all threads are affected.  This is essential if you want to take a profililng snapshot of a running application.

We now use this extensively, to monitor the live behaviour of our EVE game servers.  A HTTP backend server is used to control the profiler (profile.enable(), profile disable() at runtime) and explore its output.

I haven't seen any feadback on these submissions and would appreciate some.

Cheers,
Kristj?n
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100817/2de5bc8c/attachment.html>

From ncoghlan at gmail.com  Tue Aug 17 12:03:49 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 17 Aug 2010 20:03:49 +1000
Subject: [Python-Dev] cProfile and threads
In-Reply-To: <930F189C8A437347B80DF2C156F7EC7F0B8DEA10AB@exchis.ccp.ad.local>
References: <930F189C8A437347B80DF2C156F7EC7F0B8DEA10AB@exchis.ccp.ad.local>
Message-ID: <AANLkTi=PDBnoZK4_id58+ko6STj7G-GFYEnCubtFyB8m@mail.gmail.com>

2010/8/17 Kristj?n Valur J?nsson <kristjan at ccpgames.com>:
> Hello there.
>
> I?d like to draw your attention to two feature requests / patches that I?ve
> subbmitted:
>
> http://bugs.python.org/issue9609
> http://bugs.python.org/issue9622
>
> These patches are the result of work that we have done in profiling
> Stackless Python server applications at runtime, but they apply just as well
> to C Python.

Both look like good ideas to me (multi-threaded profiling and
debugging is fairly painful and it would be good to be able to do
something to improve that situation).

> The first patch makes _lsprof, the engine behind cProfile, multi-stack
> aware.? This allows the same cProfiler.Profile() instance to be active on
> multiple python threads and still meaningful information is gathered.

I'm curious as to the memory impact this has on the profiler (it
obviously can't be too bad if you're able to run it against your live
servers).

> The second patch allows to set the trace/profile function in python
> globally, so that all threads are affected.? This is essential if you want
> to take a profililng snapshot of a running application.

One minor quibble here is that I would suggest using "global=False" in
your docstring signatures.

Both patches seem to be missing updates to the relevant documentation.
I expect this would be difficult to unit test properly, but at least
some basic tests to check that the new global configuration of
settrace and setprofile don't blow, and that a profiler can be shared
between two threads would be good.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From kristjan at ccpgames.com  Tue Aug 17 12:16:47 2010
From: kristjan at ccpgames.com (=?iso-8859-1?Q?Kristj=E1n_Valur_J=F3nsson?=)
Date: Tue, 17 Aug 2010 10:16:47 +0000
Subject: [Python-Dev] cProfile and threads
In-Reply-To: <AANLkTi=PDBnoZK4_id58+ko6STj7G-GFYEnCubtFyB8m@mail.gmail.com>
References: <930F189C8A437347B80DF2C156F7EC7F0B8DEA10AB@exchis.ccp.ad.local>
	<AANLkTi=PDBnoZK4_id58+ko6STj7G-GFYEnCubtFyB8m@mail.gmail.com>
Message-ID: <930F189C8A437347B80DF2C156F7EC7F0B8DEA10DC@exchis.ccp.ad.local>



> -----Original Message-----
> From: Nick Coghlan [mailto:ncoghlan at gmail.com]
> Sent: 17. ?g?st 2010 10:04
> 
> Both look like good ideas to me (multi-threaded profiling and debugging is
> fairly painful and it would be good to be able to do something to improve
> that situation).
> 
Indeed.  I expect that profiling web server frameworks would be a good candidate, since a "profile page" can
be easily set up.

> > The first patch makes _lsprof, the engine behind cProfile, multi-stack
> > aware.? This allows the same cProfiler.Profile() instance to be active
> > on multiple python threads and still meaningful information is gathered.
> 
> I'm curious as to the memory impact this has on the profiler (it obviously can't
> be too bad if you're able to run it against your live servers).
The change is minimal.  We have to have an extra rotatingtree to match tls to stack
anchor points.  There are also a few extra members in the profiling "Context" entries,
but these are ephemeral.

> 
> One minor quibble here is that I would suggest using "global=False" in your
> docstring signatures.
Okay.  The docs also need to be in line with the docstrings (e.g. the docs
say "setprofile(profilefunc)" while the docstring says "setprofile(function)"
> 
> Both patches seem to be missing updates to the relevant documentation.
Yes, this is intentional.  I didn't want to waste effort on writing documentation
before having exposed this to you.  Sometimes my good ideas turn out to be
not so good and end up being rejected.

> I expect this would be difficult to unit test properly, but at least some basic
> tests to check that the new global configuration of settrace and setprofile
> don't blow, and that a profiler can be shared between two threads would be
> good.
This is my intention too, but again, I wanted to give this some airing first.
What't I probably end up doing is setting up a few threads, have them do
some token work, and then do analysis on the Profile.stats member to make
sure that all of them were accounted for and all and only callgraph relations
show up.

Kristj?n

From solipsis at pitrou.net  Tue Aug 17 12:31:30 2010
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Tue, 17 Aug 2010 12:31:30 +0200
Subject: [Python-Dev] cProfile and threads
References: <930F189C8A437347B80DF2C156F7EC7F0B8DEA10AB@exchis.ccp.ad.local>
Message-ID: <20100817123130.0ba275c8@pitrou.net>

On Tue, 17 Aug 2010 09:22:15 +0000
Kristj?n Valur J?nsson <kristjan at ccpgames.com> wrote:
> Hello there.
> I'd like to draw your attention to two feature requests / patches that I've subbmitted:
> http://bugs.python.org/issue9609
> http://bugs.python.org/issue9622
> 
> These patches are the result of work that we have done in profiling Stackless Python server applications at runtime, but they apply just as well to C Python.
> The first patch makes _lsprof, the engine behind cProfile, multi-stack aware.  This allows the same cProfiler.Profile() instance to be active on multiple python threads and still meaningful information is gathered.

Does that mean you're proposing code for inclusion in CPython that can
only be tested with Stackless?
Can't Stackless use its own patches instead?

> The second patch allows to set the trace/profile function in python globally, so that all threads are affected.  This is essential if you want to take a profililng snapshot of a running application.

I've often heard that cProfile didn't give correct profiling
information with multiple threads. Is it true?

Thanks

Antoine.



From solipsis at pitrou.net  Tue Aug 17 12:38:12 2010
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Tue, 17 Aug 2010 12:38:12 +0200
Subject: [Python-Dev] cProfile and threads
References: <930F189C8A437347B80DF2C156F7EC7F0B8DEA10AB@exchis.ccp.ad.local>
	<20100817123130.0ba275c8@pitrou.net>
Message-ID: <20100817123812.5ba64fa2@pitrou.net>


Ok, I've looked at the patch and it's actually stackless-agnostic.

Regards

Antoine.


On Tue, 17 Aug 2010 12:31:30 +0200
Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Tue, 17 Aug 2010 09:22:15 +0000
> Kristj?n Valur J?nsson <kristjan at ccpgames.com> wrote:
> > Hello there.
> > I'd like to draw your attention to two feature requests / patches that I've subbmitted:
> > http://bugs.python.org/issue9609
> > http://bugs.python.org/issue9622
> > 
> > These patches are the result of work that we have done in profiling Stackless Python server applications at runtime, but they apply just as well to C Python.
> > The first patch makes _lsprof, the engine behind cProfile, multi-stack aware.  This allows the same cProfiler.Profile() instance to be active on multiple python threads and still meaningful information is gathered.
> 
> Does that mean you're proposing code for inclusion in CPython that can
> only be tested with Stackless?
> Can't Stackless use its own patches instead?
> 
> > The second patch allows to set the trace/profile function in python globally, so that all threads are affected.  This is essential if you want to take a profililng snapshot of a running application.
> 
> I've often heard that cProfile didn't give correct profiling
> information with multiple threads. Is it true?
> 
> Thanks
> 
> Antoine.



From kristjan at ccpgames.com  Tue Aug 17 12:46:11 2010
From: kristjan at ccpgames.com (=?iso-8859-1?Q?Kristj=E1n_Valur_J=F3nsson?=)
Date: Tue, 17 Aug 2010 10:46:11 +0000
Subject: [Python-Dev] cProfile and threads
In-Reply-To: <20100817123130.0ba275c8@pitrou.net>
References: <930F189C8A437347B80DF2C156F7EC7F0B8DEA10AB@exchis.ccp.ad.local>
	<20100817123130.0ba275c8@pitrou.net>
Message-ID: <930F189C8A437347B80DF2C156F7EC7F0B8DEA10FC@exchis.ccp.ad.local>



> -----Original Message-----
> From: python-dev-bounces+kristjan=ccpgames.com at python.org
> [mailto:python-dev-bounces+kristjan=ccpgames.com at python.org] On
> Behalf Of Antoine Pitrou
> 
> Does that mean you're proposing code for inclusion in CPython that can only
> be tested with Stackless?
> Can't Stackless use its own patches instead?
> 
While this work originated with Stackless, I have gone through the trouble of porting it to
CPython, because it is relevant for CPython too.  Multiple "stacks" translates to multiple "threads"
in C Python.
 (Confusingly though, the _lsprof.c patch actually has a #ifdef STACKLESS that I forgot to remove.  Sorry about that)

> 
> I've often heard that cProfile didn't give correct profiling information with
> multiple threads. Is it true?
Yes, and that's the purpose of this submission:  To fix exactly that.


K

From ncoghlan at gmail.com  Tue Aug 17 13:21:45 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 17 Aug 2010 21:21:45 +1000
Subject: [Python-Dev] cProfile and threads
In-Reply-To: <930F189C8A437347B80DF2C156F7EC7F0B8DEA10DC@exchis.ccp.ad.local>
References: <930F189C8A437347B80DF2C156F7EC7F0B8DEA10AB@exchis.ccp.ad.local>
	<AANLkTi=PDBnoZK4_id58+ko6STj7G-GFYEnCubtFyB8m@mail.gmail.com>
	<930F189C8A437347B80DF2C156F7EC7F0B8DEA10DC@exchis.ccp.ad.local>
Message-ID: <AANLkTin+m9V6Ne2vTuMOCoJ6p-9+ZJ4nZpihEmU+TE8h@mail.gmail.com>

2010/8/17 Kristj?n Valur J?nsson <kristjan at ccpgames.com>:
> Yes, this is intentional. ?I didn't want to waste effort on writing documentation
> before having exposed this to you. ?Sometimes my good ideas turn out to be
> not so good and end up being rejected.

Cool, I thought it would be something like that. In this case, at
least from where I'm standing, your good idea looks like a good one.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From anders.sandvig at gmail.com  Tue Aug 17 13:59:28 2010
From: anders.sandvig at gmail.com (Anders Sandvig)
Date: Tue, 17 Aug 2010 13:59:28 +0200
Subject: [Python-Dev] i18n
In-Reply-To: <20100814081816.GC49566@nexus.in-nomine.org>
References: <AANLkTinv=a8f3kO56CJ3FUgSZPh23fuSs7zyaofj=GMM@mail.gmail.com>
	<20100814081816.GC49566@nexus.in-nomine.org>
Message-ID: <AANLkTinAYVWrqw2tO3DaY7rb+n8xLQgv6ri_RkxwYCJH@mail.gmail.com>

On Sat, Aug 14, 2010 at 10:18 AM, Jeroen Ruigrok van der Werven
<asmodai at in-nomine.org> wrote:
> I doubt you will be able to localize much with regard to the interpreter.
> The only thing that really comes to mind are the error and exception
> messages, but you will never be able to localize the errors themselves. The
> problem there is that if they seek help on international fora for Python,
> other people might have no clue what the (error) message even means.

I think one way to solve this might be to include the original
(English) error message as well as the translation. I've noticed this
is how error messages are handled in localized versions of Oracle, and
although I'm personally annoyed by it, I can see how some people might
find it useful.

For example:

>>> cause.error()
Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
NameError: name 'cause' is not defined

localized to Norwegian, could become:

>>> cause.error()
Tilbakesporing (nyeste kall sist):
    Fil "<stdin>", linje 1, i <module>
NameError: navn 'cause' er ikke definert (name 'cause' is not defined)

I think translating the actual error text would make sense, but I'm
not so sure about localizing the traceback output itself...


Anders

From steve at holdenweb.com  Tue Aug 17 15:13:14 2010
From: steve at holdenweb.com (Steve Holden)
Date: Tue, 17 Aug 2010 09:13:14 -0400
Subject: [Python-Dev] Dev FAQ update request for svnmerge
In-Reply-To: <20100817054503.GA14238@remy>
References: <AANLkTinsj65AAL-wYRMug3gH-=q7hCjr=92MkW_02vTk@mail.gmail.com>
	<20100817054503.GA14238@remy>
Message-ID: <i4e1tj$a72$1@dough.gmane.org>

On 8/17/2010 1:45 AM, Senthil Kumaran wrote:
> On Tue, Aug 17, 2010 at 03:08:31PM +1000, Nick Coghlan wrote:
>> Could someone who knows how it is currently set up suggest a
>> correction to the dev FAQ for svnmerge usage?
> 
> 
> 2.26   How do I merge between branches?
> 
> All development occurs under the py3k branch and bug fixes are expected to be

All development occurs under the py3k branch. Bug fixes (and ONLY bug
fixes: no new features should be added to micro releases) should be

> merged into two additional branches, which are release2x-maint and
> release3x-maint.
> 
> Assuming a change is committed into py3k as revision 0001, you
> merge into the release2x-maint by doing:
> 
> # In the release2x-maint branch checkout.
> svnmerge.py merge -r 0001
> svn commit -F svnmerge-commit-message.txt  # r0002
> 
> # In a release3x-maint checkout.
> svnmerge.py merge -r 0001
> svn commit -F svnmerge-commit-message.txt  # r0003
> 
> 
> # Optional
> 
> In rare situations where you want to backport a security fix or a
> documentation fix into release26-maint branch: 
> 
> #In the release26-maint checkout.
> 
> svnmerge merge -S /python/branches/release27-maint -r0002
> svn commit -F svnmerge-commit-message.txt  # r0004
> 
> 
> 
regards
 Steve
-- 
Steve Holden           +1 571 484 6266   +1 800 494 3119
DjangoCon US September 7-9, 2010    http://djangocon.us/
See Python Video!       http://python.mirocommunity.org/
Holden Web LLC                 http://www.holdenweb.com/


From daniel at stutzbachenterprises.com  Tue Aug 17 20:31:48 2010
From: daniel at stutzbachenterprises.com (Daniel Stutzbach)
Date: Tue, 17 Aug 2010 13:31:48 -0500
Subject: [Python-Dev] cProfile and threads
In-Reply-To: <930F189C8A437347B80DF2C156F7EC7F0B8DEA10AB@exchis.ccp.ad.local>
References: <930F189C8A437347B80DF2C156F7EC7F0B8DEA10AB@exchis.ccp.ad.local>
Message-ID: <AANLkTi=79vs=12tuug7Mp+aD3UkJ34YfanvXKET00h-6@mail.gmail.com>

2010/8/17 Kristj?n Valur J?nsson <kristjan at ccpgames.com>

> These patches are the result of work that we have done in profiling
> Stackless Python server applications at runtime, but they apply just as well
> to C Python.
>
> The first patch makes _lsprof, the engine behind cProfile, multi-stack
> aware.  This allows the same cProfiler.Profile() instance to be active on
> multiple python threads and still meaningful information is gathered.
>

+1


> The second patch allows to set the trace/profile function in python *
> globally*, so that all threads are affected.  This is essential if you
> want to take a profililng snapshot of a running application.
>

+1
--
Daniel Stutzbach, Ph.D.
President, Stutzbach Enterprises, LLC <http://stutzbachenterprises.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100817/97d91090/attachment.html>

From tjreedy at udel.edu  Tue Aug 17 20:39:47 2010
From: tjreedy at udel.edu (Terry Reedy)
Date: Tue, 17 Aug 2010 14:39:47 -0400
Subject: [Python-Dev] Dev FAQ update request for svnmerge
In-Reply-To: <20100817054503.GA14238@remy>
References: <AANLkTinsj65AAL-wYRMug3gH-=q7hCjr=92MkW_02vTk@mail.gmail.com>
	<20100817054503.GA14238@remy>
Message-ID: <i4el1j$o4r$1@dough.gmane.org>

On 8/17/2010 1:45 AM, Senthil Kumaran wrote:
> On Tue, Aug 17, 2010 at 03:08:31PM +1000, Nick Coghlan wrote:
>> Could someone who knows how it is currently set up suggest a
>> correction to the dev FAQ for svnmerge usage?
>
>
> 2.26   How do I merge between branches?
>
> All development occurs under the py3k branch and bug fixes are expected to be
> merged into two additional branches, which are release2x-maint and

That can and now should specifically be release27_maint as 26 is now 
effectively closed to routine bug fixes.

> release3x-maint.
>
> Assuming a change is committed into py3k as revision 0001, you
> merge into the release2x-maint by doing:
>
> # In the release2x-maint branch checkout.
> svnmerge.py merge -r 0001
> svn commit -F svnmerge-commit-message.txt  # r0002
>
> # In a release3x-maint checkout.
> svnmerge.py merge -r 0001
> svn commit -F svnmerge-commit-message.txt  # r0003
>
>
> # Optional
>
> In rare situations where you want to backport a security fix or a
> documentation fix into release26-maint branch:

I think the only doc fix would be part of a security fix, so no need to 
mention separately I think.
>
> #In the release26-maint checkout.
>
> svnmerge merge -S /python/branches/release27-maint -r0002
> svn commit -F svnmerge-commit-message.txt  # r0004
>
>
>


-- 
Terry Jan Reedy


From barry at python.org  Tue Aug 17 21:55:20 2010
From: barry at python.org (Barry Warsaw)
Date: Tue, 17 Aug 2010 15:55:20 -0400
Subject: [Python-Dev] Python 2.6.6 release candidate 2 now available.
Message-ID: <20100817155520.0d02675f@heresy>

Hello fellow Python enthusiasts,

The source tarballs and Windows installers for the second (and hopefully last)
Python 2.6.6 release candidate is now available:

    http://www.python.org/download/releases/2.6.6/

We've had a handful of important fixes since rc1, and of course a huge number
of bugs have been fixed since 2.6.5, with the full NEWS file available here:

    http://www.python.org/download/releases/2.6.6/NEWS.txt

We would love it if you can download, install, and test this version with your
favorite projects and on your favorite platforms.  We expect to release Python
2.6.6 final on August 24, 2010.

Please note that with the release of Python 2.7 final on July 3, 2010, and in
accordance with Python policy, Python 2.6.6 is the last scheduled bug fix
maintenance release of the 2.6 series.  Because of this, your testing of this
release candidate will help immensely.  We plan on continuing to support
source-only security fixes in Python 2.6 for the next five years.

My thanks go out to everyone who has contributed with code, testing and bug
tracker gardening for Python 2.6.6.  The excellent folks on #python-dev are
true Pythonic heros.

Enjoy,
-Barry
(on behalf of the Python development community)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100817/a9ee5a11/attachment.pgp>

From barry at python.org  Tue Aug 17 23:17:00 2010
From: barry at python.org (Barry Warsaw)
Date: Tue, 17 Aug 2010 17:17:00 -0400
Subject: [Python-Dev] PEP 3149 - updated patch
Message-ID: <20100817171700.0c1c22dc@heresy>

I've re-merged the py3k trunk to my PEP 3149 branch and uploaded a new diff.
For reference, here's the PEP:

    http://www.python.org/dev/peps/pep-3149/

and the tracker issue:

    http://bugs.python.org/issue9193

along with the updated patch:

    http://bugs.python.org/file18558/pep3149.txt

and the Launchpad branch:

    https://code.edge.launchpad.net/~barry/python/sovers

I'd like to know if anybody has additional feedback, suggestions, or
objections that you think still need to be addressed.  You can follow up here
or in the tracker.

Now that 2.6.6 is almost off my plate, I'd like to bring this PEP to its
(hopefully successful) conclusion.

Cheers,
-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100817/588d7fd5/attachment-0001.pgp>

From benjamin at python.org  Wed Aug 18 01:00:59 2010
From: benjamin at python.org (Benjamin Peterson)
Date: Tue, 17 Aug 2010 18:00:59 -0500
Subject: [Python-Dev] [Python-checkins] r84166 -
	python/branches/py3k/Misc/developers.txt
In-Reply-To: <20100817225842.37A51EEA44@mail.python.org>
References: <20100817225842.37A51EEA44@mail.python.org>
Message-ID: <AANLkTimh38KO3ZqCNoGPq6BBaYk78dwNDkdgJZuUdWt6@mail.gmail.com>

2010/8/17 martin.v.loewis <python-checkins at python.org>:
> Author: martin.v.loewis
> Date: Wed Aug 18 00:58:42 2010
> New Revision: 84166
>
> Log:
> Add Ask Solem.
>
>
> Modified:
> ? python/branches/py3k/Misc/developers.txt
>
> Modified: python/branches/py3k/Misc/developers.txt
> ==============================================================================
> --- python/branches/py3k/Misc/developers.txt ? ?(original)
> +++ python/branches/py3k/Misc/developers.txt ? ?Wed Aug 18 00:58:42 2010
> @@ -20,6 +20,10 @@
> ?Permissions History
> ?-------------------
>
> +- Ask Solem was given commit access on Aug 17 2010 by MvL,
> + ?on recommendation by Jesse Noller, for work on the subprocess
> + ?library.

IIRC it was multiprocessing.



-- 
Regards,
Benjamin

From ndbecker2 at gmail.com  Wed Aug 18 14:34:23 2010
From: ndbecker2 at gmail.com (Neal Becker)
Date: Wed, 18 Aug 2010 08:34:23 -0400
Subject: [Python-Dev] multi-version parallel-installed modules
Message-ID: <i4gk0h$i9p$1@dough.gmane.org>

Is there any proposal to accommodate having parallel-installed multiple 
versions of modules?

I have client code in multiple projects using version x.y of a C-compiled 
module A.

I want to test a new version x.z of module A, but all client software needs 
to be recompiled against the new version.  If I just install the module, all 
the other client software breaks.

I know I could test using virtualenv, but there would be a lot of modules to 
install into virtualenv to run the tests, so this would be cumbersome.  I'd 
prefer to have multiple version co-exist so I could update projects to the 
new version at my convenience.

How does this situation happen?  I have lots of c++ code using pyublas, 
which allows c++ code written to the boost::ublas interface to operate on 
numpy vectors/matrixes.  pyublas is built against boost libs. pyublas 
installs a module, whose purpose is to register conversions.

When I update boost libs, I have to rebuild pyublas and install the updated 
module.  Then rebuild my client software modules.  If pyublas is built 
against a different boost version than my client modules, the conversions 
will fail.


From fuzzyman at voidspace.org.uk  Wed Aug 18 14:50:20 2010
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Wed, 18 Aug 2010 15:50:20 +0300
Subject: [Python-Dev] multi-version parallel-installed modules
In-Reply-To: <i4gk0h$i9p$1@dough.gmane.org>
References: <i4gk0h$i9p$1@dough.gmane.org>
Message-ID: <4C6BD70C.5040205@voidspace.org.uk>

On 18/08/2010 15:34, Neal Becker wrote:
> Is there any proposal to accommodate having parallel-installed multiple
> versions of modules?
>
> I have client code in multiple projects using version x.y of a C-compiled
> module A.
>
> I want to test a new version x.z of module A, but all client software needs
> to be recompiled against the new version.  If I just install the module, all
> the other client software breaks.
>
> I know I could test using virtualenv, but there would be a lot of modules to
> install into virtualenv to run the tests, so this would be cumbersome.  I'd
> prefer to have multiple version co-exist so I could update projects to the
> new version at my convenience.
>
> How does this situation happen?  I have lots of c++ code using pyublas,
> which allows c++ code written to the boost::ublas interface to operate on
> numpy vectors/matrixes.  pyublas is built against boost libs. pyublas
> installs a module, whose purpose is to register conversions.
>
> When I update boost libs, I have to rebuild pyublas and install the updated
> module.  Then rebuild my client software modules.  If pyublas is built
> against a different boost version than my client modules, the conversions
> will fail.
>    

I believe that setuptools / distribute already has a mechanism for 
supporting this. It basically does it with sys.path hackery.

As far as I know there are no plans to include this in distutils2 - but 
Tarek can correct me if I am wrong.

All the best,

Michael Foord

> _______________________________________________
> Python-Dev mailing list
> Python-Dev at 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/


From mal at egenix.com  Wed Aug 18 15:29:15 2010
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed, 18 Aug 2010 15:29:15 +0200
Subject: [Python-Dev] multi-version parallel-installed modules
In-Reply-To: <4C6BD70C.5040205@voidspace.org.uk>
References: <i4gk0h$i9p$1@dough.gmane.org> <4C6BD70C.5040205@voidspace.org.uk>
Message-ID: <4C6BE02B.2050806@egenix.com>

Michael Foord wrote:
> On 18/08/2010 15:34, Neal Becker wrote:
>> Is there any proposal to accommodate having parallel-installed multiple
>> versions of modules?

You can easily implement such a setup by placing the module versions
into a separate dir and then adding the right version dir to you
sys.path before test startup.

E.g.

export PYTHONPATH=mymodule/3.0; python test.py
export PYTHONPATH=mymodule/3.1; python test.py

>> I have client code in multiple projects using version x.y of a C-compiled
>> module A.
>>
>> I want to test a new version x.z of module A, but all client software
>> needs
>> to be recompiled against the new version.  If I just install the
>> module, all
>> the other client software breaks.
>>
>> I know I could test using virtualenv, but there would be a lot of
>> modules to
>> install into virtualenv to run the tests, so this would be
>> cumbersome.  I'd
>> prefer to have multiple version co-exist so I could update projects to
>> the
>> new version at my convenience.
>>
>> How does this situation happen?  I have lots of c++ code using pyublas,
>> which allows c++ code written to the boost::ublas interface to operate on
>> numpy vectors/matrixes.  pyublas is built against boost libs. pyublas
>> installs a module, whose purpose is to register conversions.
>>
>> When I update boost libs, I have to rebuild pyublas and install the
>> updated
>> module.  Then rebuild my client software modules.  If pyublas is built
>> against a different boost version than my client modules, the conversions
>> will fail.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Aug 18 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/
________________________________________________________________________

::: 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/

From jnoller at gmail.com  Wed Aug 18 15:49:20 2010
From: jnoller at gmail.com (Jesse Noller)
Date: Wed, 18 Aug 2010 09:49:20 -0400
Subject: [Python-Dev] [Python-checkins] r84166 -
	python/branches/py3k/Misc/developers.txt
In-Reply-To: <AANLkTimh38KO3ZqCNoGPq6BBaYk78dwNDkdgJZuUdWt6@mail.gmail.com>
References: <20100817225842.37A51EEA44@mail.python.org>
	<AANLkTimh38KO3ZqCNoGPq6BBaYk78dwNDkdgJZuUdWt6@mail.gmail.com>
Message-ID: <AANLkTikdSAC6dH=kKA5km+5OW5=bx-23RXZSZsB+j16J@mail.gmail.com>

On Tue, Aug 17, 2010 at 7:00 PM, Benjamin Peterson <benjamin at python.org> wrote:
> 2010/8/17 martin.v.loewis <python-checkins at python.org>:
>> Author: martin.v.loewis
>> Date: Wed Aug 18 00:58:42 2010
>> New Revision: 84166
>>
>> Log:
>> Add Ask Solem.
>>
>>
>> Modified:
>> ? python/branches/py3k/Misc/developers.txt
>>
>> Modified: python/branches/py3k/Misc/developers.txt
>> ==============================================================================
>> --- python/branches/py3k/Misc/developers.txt ? ?(original)
>> +++ python/branches/py3k/Misc/developers.txt ? ?Wed Aug 18 00:58:42 2010
>> @@ -20,6 +20,10 @@
>> ?Permissions History
>> ?-------------------
>>
>> +- Ask Solem was given commit access on Aug 17 2010 by MvL,
>> + ?on recommendation by Jesse Noller, for work on the subprocess
>> + ?library.
>
> IIRC it was multiprocessing.
>
>
>
> --
> Regards,
> Benjamin

Benjamin's correct

From fuzzyman at voidspace.org.uk  Wed Aug 18 17:11:18 2010
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Wed, 18 Aug 2010 18:11:18 +0300
Subject: [Python-Dev] Fwd: Old link text in documentation
Message-ID: <4C6BF816.80403@voidspace.org.uk>

Could (and should) the online Python 3.1 docs be updated to show Python 
2.7 as stable?

All the best,

Michael

-------- Original Message --------
Subject: 	Old link text in documentation
Date: 	Sun, 15 Aug 2010 15:49:34 -0700
From: 	Aaron DeVore <aaron.devore at gmail.com>
To: 	webmaster at python.org



The link text at http://docs.python.org/py3k/ under "Docs for other
versions" still describes 2.7 as being "in development"

-Aaron DeVore

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100818/f92940e9/attachment.html>

From martin at v.loewis.de  Wed Aug 18 20:59:12 2010
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 18 Aug 2010 20:59:12 +0200
Subject: [Python-Dev] Fwd: Old link text in documentation
In-Reply-To: <4C6BF816.80403@voidspace.org.uk>
References: <4C6BF816.80403@voidspace.org.uk>
Message-ID: <4C6C2D80.1090301@v.loewis.de>

Am 18.08.2010 17:11, schrieb Michael Foord:
> Could (and should) the online Python 3.1 docs be updated to show Python
> 2.7 as stable?

I think the answer is "no, it could not".

How many old documentation sets would you want to go through, and
regenerate them? There is also

http://docs.python.org/release/2.6.5/
http://docs.python.org/release/2.6.4/
http://docs.python.org/release/2.6.3/

etc.

In particular,

http://docs.python.org/release/2.6.2/

still lists 3.1 as in-development.

If that would be fixed, I think the fix should work for all
documentation sets, and such a fix might be difficult to implement.

Regards,
Martin

From fuzzyman at voidspace.org.uk  Wed Aug 18 21:00:48 2010
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Wed, 18 Aug 2010 22:00:48 +0300
Subject: [Python-Dev] Fwd: Old link text in documentation
In-Reply-To: <4C6C2D80.1090301@v.loewis.de>
References: <4C6BF816.80403@voidspace.org.uk> <4C6C2D80.1090301@v.loewis.de>
Message-ID: <4C6C2DE0.60901@voidspace.org.uk>

On 18/08/2010 21:59, "Martin v. L?wis" wrote:
> Am 18.08.2010 17:11, schrieb Michael Foord:
>    
>> Could (and should) the online Python 3.1 docs be updated to show Python
>> 2.7 as stable?
>>      
> I think the answer is "no, it could not".
>
> How many old documentation sets would you want to go through, and
> regenerate them? There is also
>
> http://docs.python.org/release/2.6.5/
> http://docs.python.org/release/2.6.4/
> http://docs.python.org/release/2.6.3/
>
> etc.
>
> In particular,
>
> http://docs.python.org/release/2.6.2/
>
> still lists 3.1 as in-development.
>
> If that would be fixed, I think the fix should work for all
> documentation sets, and such a fix might be difficult to implement.
>
>    

Ok, fair enough.

Michael

> Regards,
> Martin
>    


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


From g.brandl at gmx.net  Wed Aug 18 22:06:20 2010
From: g.brandl at gmx.net (Georg Brandl)
Date: Wed, 18 Aug 2010 22:06:20 +0200
Subject: [Python-Dev] Fwd: Old link text in documentation
In-Reply-To: <4C6C2D80.1090301@v.loewis.de>
References: <4C6BF816.80403@voidspace.org.uk> <4C6C2D80.1090301@v.loewis.de>
Message-ID: <i4heg3$992$1@dough.gmane.org>

Am 18.08.2010 20:59, schrieb "Martin v. L?wis":
> Am 18.08.2010 17:11, schrieb Michael Foord:
>> Could (and should) the online Python 3.1 docs be updated to show Python
>> 2.7 as stable?
> 
> I think the answer is "no, it could not".
> 
> How many old documentation sets would you want to go through, and
> regenerate them? There is also
> 
> http://docs.python.org/release/2.6.5/
> http://docs.python.org/release/2.6.4/
> http://docs.python.org/release/2.6.3/
> 
> etc.
> 
> In particular,
> 
> http://docs.python.org/release/2.6.2/
> 
> still lists 3.1 as in-development.
> 
> If that would be fixed, I think the fix should work for all
> documentation sets, and such a fix might be difficult to implement.

Actually, the ones referred to here are the continually updated docs from
the branch head, which I just fixed to show the correct information.

I agree about the doc sets specific to releases.

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.


From greg.ewing at canterbury.ac.nz  Thu Aug 19 10:36:54 2010
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Thu, 19 Aug 2010 20:36:54 +1200
Subject: [Python-Dev] Oddity in AST for 3-argument slices
Message-ID: <4C6CED26.7040601@canterbury.ac.nz>

I've discovered a slightly surprising thing about the way
AST objects for slices are constructed. According to
Python.asdl, all three parts of a slice are optional:

    slice = Slice(expr? lower, expr? upper, expr? step)

But that's not quite the way the parser sees things:

Python 3.1.2 (r312:79147, Aug 19 2010, 20:26:20)
[GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
 >>> import ast
 >>> t = ast.parse("x[::]", mode='eval')
 >>> ast.dump(t)
"Expression(body=Subscript(value=Name(id='x', ctx=Load()), 
slice=Slice(lower=None, upper=None, step=Name(id='None', ctx=Load())), ctx=Load()))"

In other words,

    x[::]

is being parsed as though it had been written

    x[::None]

Is there a good reason for an omitted third slice
argument being treated differently from the others?

-- 
Greg

From ncoghlan at gmail.com  Thu Aug 19 11:47:32 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 19 Aug 2010 19:47:32 +1000
Subject: [Python-Dev] Oddity in AST for 3-argument slices
In-Reply-To: <4C6CED26.7040601@canterbury.ac.nz>
References: <4C6CED26.7040601@canterbury.ac.nz>
Message-ID: <AANLkTinj8ZROaUZTTUfVPNDxJRPrznbiptd3Gdoi38SE@mail.gmail.com>

On Thu, Aug 19, 2010 at 6:36 PM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> In other words,
>
> ? x[::]
>
> is being parsed as though it had been written
>
> ? x[::None]
>
> Is there a good reason for an omitted third slice
> argument being treated differently from the others?

Probably so it looks different from the AST for x[:]

>>> ast.dump(ast.parse("x[:]", mode='eval'))
"Expression(body=Subscript(value=Name(id='x', ctx=Load()),
slice=Slice(lower=None, upper=None, step=None), ctx=Load()))"
>>> ast.dump(ast.parse("x[::]", mode='eval'))
"Expression(body=Subscript(value=Name(id='x', ctx=Load()),
slice=Slice(lower=None, upper=None, step=Name(id='None', ctx=Load())),
ctx=Load()))"

Or else it's just an accident of implementation, since the AST doesn't
actually *need* to distinguish those two cases.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From ziade.tarek at gmail.com  Thu Aug 19 12:07:36 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 19 Aug 2010 12:07:36 +0200
Subject: [Python-Dev] [Python-checkins] r84190 -
	python/branches/release31-maint/Doc/library/stdtypes.rst
In-Reply-To: <4C6C630C.3000603@netwok.org>
References: <20100818224207.2A126EE981@mail.python.org>
	<4C6C630C.3000603@netwok.org>
Message-ID: <AANLkTinbajdTneC-MKDU0rN3o6+w+asnDCsNx-HS6fP8@mail.gmail.com>

On Thu, Aug 19, 2010 at 12:47 AM, ?ric Araujo <merwok at netwok.org> wrote:
> Let?s turn one error into an occasion for learning:
>
>> Log:
>> Manually merge r84187
>
> I was bad with numbers and actually ran svnmerge merge -r 81417, which
> did nothing. Since I have manually merged now, do I have to update the
> bookkeeping information manually? My understanding of the dev FAQ is:
> svnmerge block -r 84187. Is that right?

What I do is :

4 cd /the/right/branch/or/trunk
$ svn ci -m 'comment'
you get a revision number

$ cd py3k
$ svn up
$ svnmerge.py merge -r revision
$ run the tests
$ svn ci -F svn<tab>   (there's a svn*.txt file generated by the
svnmerge tool, don't do a manual comment)

Then I apply the same in all branches. Notice that if you merge
something to py3k, the merge to the 3.x
release branch is done with the revision number of the py3k commit,
not the original one.

And I use "svnmerge block -r revision" for branches where the commit
should not be applied, don't forget to do this.
(same revision number cascading applies)

Let me know if you have any other issue

Cheers
arek
>
> Thank you.
>
> _______________________________________________
> Python-checkins mailing list
> Python-checkins at python.org
> http://mail.python.org/mailman/listinfo/python-checkins
>



-- 
Tarek Ziad? | http://ziade.org

From victor.stinner at haypocalc.com  Thu Aug 19 12:17:45 2010
From: victor.stinner at haypocalc.com (Victor Stinner)
Date: Thu, 19 Aug 2010 12:17:45 +0200
Subject: [Python-Dev] [Python-checkins] r84190 -
	python/branches/release31-maint/Doc/library/stdtypes.rst
In-Reply-To: <AANLkTinbajdTneC-MKDU0rN3o6+w+asnDCsNx-HS6fP8@mail.gmail.com>
References: <20100818224207.2A126EE981@mail.python.org>
	<4C6C630C.3000603@netwok.org>
	<AANLkTinbajdTneC-MKDU0rN3o6+w+asnDCsNx-HS6fP8@mail.gmail.com>
Message-ID: <201008191217.45111.victor.stinner@haypocalc.com>

Le jeudi 19 ao?t 2010 12:07:36, Tarek Ziad? a ?crit :
> What I do is :
> 
> 4 cd /the/right/branch/or/trunk
> $ svn ci -m 'comment'
> you get a revision number
> 
> $ cd py3k
> $ svn up
> $ svnmerge.py merge -r revision
> (...)

Wrong. trunk branch is dead, py3k is the new main branch ;-)

-- 
Victor Stinner
http://www.haypocalc.com/

From ziade.tarek at gmail.com  Thu Aug 19 12:21:10 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 19 Aug 2010 12:21:10 +0200
Subject: [Python-Dev] [Python-checkins] r84190 -
	python/branches/release31-maint/Doc/library/stdtypes.rst
In-Reply-To: <201008191217.45111.victor.stinner@haypocalc.com>
References: <20100818224207.2A126EE981@mail.python.org>
	<4C6C630C.3000603@netwok.org>
	<AANLkTinbajdTneC-MKDU0rN3o6+w+asnDCsNx-HS6fP8@mail.gmail.com>
	<201008191217.45111.victor.stinner@haypocalc.com>
Message-ID: <AANLkTimKUZ42SCk8y06yhkNK9UtS+iqJYGT_-6yNSD3s@mail.gmail.com>

On Thu, Aug 19, 2010 at 12:17 PM, Victor Stinner
<victor.stinner at haypocalc.com> wrote:
> Le jeudi 19 ao?t 2010 12:07:36, Tarek Ziad? a ?crit :
>> What I do is :
>>
>> 4 cd /the/right/branch/or/trunk
>> $ svn ci -m 'comment'
>> you get a revision number
>>
>> $ cd py3k
>> $ svn up
>> $ svnmerge.py merge -r revision
>> (...)
>
> Wrong. trunk branch is dead, py3k is the new main branch ;-)


s/trunk/2.7 branch/

>
> --
> Victor Stinner
> http://www.haypocalc.com/
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/ziade.tarek%40gmail.com
>



-- 
Tarek Ziad? | http://ziade.org

From greg.ewing at canterbury.ac.nz  Thu Aug 19 12:35:34 2010
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Thu, 19 Aug 2010 22:35:34 +1200
Subject: [Python-Dev] Oddity in AST for 3-argument slices
In-Reply-To: <AANLkTinj8ZROaUZTTUfVPNDxJRPrznbiptd3Gdoi38SE@mail.gmail.com>
References: <4C6CED26.7040601@canterbury.ac.nz>
	<AANLkTinj8ZROaUZTTUfVPNDxJRPrznbiptd3Gdoi38SE@mail.gmail.com>
Message-ID: <4C6D08F6.2000706@canterbury.ac.nz>

Nick Coghlan wrote:

> Or else it's just an accident of implementation, since the AST doesn't
> actually *need* to distinguish those two cases.

It doesn't seem to be an accident, because ast_for_slice()
goes out of its way to manufacture a Name node for the
missing argument.

It doesn't seem to significantly simplify the compiler
either, because compiler_slice() could just as easily
treat it the same way as the other slice arguments and
emit an instruction to load None if it's missing.

So it's a mystery. Perhaps it made life easier for some
earlier version of the compiler.

-- 
Greg



From merwok at netwok.org  Thu Aug 19 13:55:35 2010
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Thu, 19 Aug 2010 13:55:35 +0200
Subject: [Python-Dev] [Python-checkins] r84190 -
	python/branches/release31-maint/Doc/library/stdtypes.rst
In-Reply-To: <AANLkTinbajdTneC-MKDU0rN3o6+w+asnDCsNx-HS6fP8@mail.gmail.com>
References: <20100818224207.2A126EE981@mail.python.org>	<4C6C630C.3000603@netwok.org>
	<AANLkTinbajdTneC-MKDU0rN3o6+w+asnDCsNx-HS6fP8@mail.gmail.com>
Message-ID: <4C6D1BB7.2010101@netwok.org>

Thanks for the replies.

The dev FAQ is clear about regular use, it tells about the
svnmerge-commit-message too, and people in #python-dev have told me that
the merge order is py3k > 3.1, py3k > 2.7. My problem here is that I
committed r84190 in 3.1 manually, but it should have been an svnmerge of
r84187. So my question is: Do I have to svnmerge block -r84187 in 3.1?

> And I use "svnmerge block -r revision" for branches where the commit
> should not be applied, don't forget to do this.

Oh, this has to be done for every commit? I have for example fixed typos
in 3.x that don?t apply to 2.7, so I have to block them?

Regards


From eric at trueblade.com  Thu Aug 19 14:00:58 2010
From: eric at trueblade.com (Eric Smith)
Date: Thu, 19 Aug 2010 08:00:58 -0400
Subject: [Python-Dev] [Python-checkins] r84190
	-	python/branches/release31-maint/Doc/library/stdtypes.rst
In-Reply-To: <4C6D1BB7.2010101@netwok.org>
References: <20100818224207.2A126EE981@mail.python.org>	<4C6C630C.3000603@netwok.org>	<AANLkTinbajdTneC-MKDU0rN3o6+w+asnDCsNx-HS6fP8@mail.gmail.com>
	<4C6D1BB7.2010101@netwok.org>
Message-ID: <4C6D1CFA.6050601@trueblade.com>

On 8/19/2010 7:55 AM, ?ric Araujo wrote:
> Thanks for the replies.
>
> The dev FAQ is clear about regular use, it tells about the
> svnmerge-commit-message too, and people in #python-dev have told me that
> the merge order is py3k>  3.1, py3k>  2.7. My problem here is that I
> committed r84190 in 3.1 manually, but it should have been an svnmerge of
> r84187. So my question is: Do I have to svnmerge block -r84187 in 3.1?

Yes, you should do that.

>> And I use "svnmerge block -r revision" for branches where the commit
>> should not be applied, don't forget to do this.
>
> Oh, this has to be done for every commit? I have for example fixed typos
> in 3.x that don?t apply to 2.7, so I have to block them?

I don't know that this matters, since I don't think anyone's doing mass 
merges in this direction. I tend to do it just for my own bookkeeping 
purposes, though.

Eric.

From ziade.tarek at gmail.com  Thu Aug 19 14:20:45 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 19 Aug 2010 14:20:45 +0200
Subject: [Python-Dev] [Python-checkins] r84190 -
	python/branches/release31-maint/Doc/library/stdtypes.rst
In-Reply-To: <4C6D1CFA.6050601@trueblade.com>
References: <20100818224207.2A126EE981@mail.python.org>
	<4C6C630C.3000603@netwok.org>
	<AANLkTinbajdTneC-MKDU0rN3o6+w+asnDCsNx-HS6fP8@mail.gmail.com>
	<4C6D1BB7.2010101@netwok.org> <4C6D1CFA.6050601@trueblade.com>
Message-ID: <AANLkTinzQeA2Djj5GyPZWKYwVnQxcLjzbgJsfo-GgDe9@mail.gmail.com>

On Thu, Aug 19, 2010 at 2:00 PM, Eric Smith <eric at trueblade.com> wrote:
> On 8/19/2010 7:55 AM, ?ric Araujo wrote:
>>
>> Thanks for the replies.
>>
>> The dev FAQ is clear about regular use, it tells about the
>> svnmerge-commit-message too, and people in #python-dev have told me that
>> the merge order is py3k> ?3.1, py3k> ?2.7. My problem here is that I
>> committed r84190 in 3.1 manually, but it should have been an svnmerge of
>> r84187. So my question is: Do I have to svnmerge block -r84187 in 3.1?
>
> Yes, you should do that.
>
>>> And I use "svnmerge block -r revision" for branches where the commit
>>> should not be applied, don't forget to do this.
>>
>> Oh, this has to be done for every commit? I have for example fixed typos
>> in 3.x that don?t apply to 2.7, so I have to block them?
>
> I don't know that this matters, since I don't think anyone's doing mass
> merges in this direction. I tend to do it just for my own bookkeeping
> purposes, though.

I do it every time myself, AFAIK it reduces the workload of people
that are making sure
all pending patches were applied.  Not doing a block right away for me means:
I need to merge it to that branch, but I can't do it now (lack of
time, or imminent release)

From ncoghlan at gmail.com  Thu Aug 19 15:26:21 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 19 Aug 2010 23:26:21 +1000
Subject: [Python-Dev] Oddity in AST for 3-argument slices
In-Reply-To: <4C6D08F6.2000706@canterbury.ac.nz>
References: <4C6CED26.7040601@canterbury.ac.nz>
	<AANLkTinj8ZROaUZTTUfVPNDxJRPrznbiptd3Gdoi38SE@mail.gmail.com>
	<4C6D08F6.2000706@canterbury.ac.nz>
Message-ID: <AANLkTinFoXG1xn3ZsZ16uBLJXj+SsqS8V_tiPnd4rTwF@mail.gmail.com>

On Thu, Aug 19, 2010 at 8:35 PM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Nick Coghlan wrote:
>
>> Or else it's just an accident of implementation, since the AST doesn't
>> actually *need* to distinguish those two cases.
>
> It doesn't seem to be an accident, because ast_for_slice()
> goes out of its way to manufacture a Name node for the
> missing argument.
>
> It doesn't seem to significantly simplify the compiler
> either, because compiler_slice() could just as easily
> treat it the same way as the other slice arguments and
> emit an instruction to load None if it's missing.
>
> So it's a mystery. Perhaps it made life easier for some
> earlier version of the compiler.

Ah, it's a 2.x-ism. The old compiler needed to know whether or not to
try __get/set/delslice__ (yes for x[:], no for x[::]). With those
magic methods gone, that would make it obsolete in 3.x, so x[::]
should probably just be changed to generate the same AST as x[:] now.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From ncoghlan at gmail.com  Thu Aug 19 15:32:09 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 19 Aug 2010 23:32:09 +1000
Subject: [Python-Dev] [Python-checkins] r84190 -
	python/branches/release31-maint/Doc/library/stdtypes.rst
In-Reply-To: <4C6D1BB7.2010101@netwok.org>
References: <20100818224207.2A126EE981@mail.python.org>
	<4C6C630C.3000603@netwok.org>
	<AANLkTinbajdTneC-MKDU0rN3o6+w+asnDCsNx-HS6fP8@mail.gmail.com>
	<4C6D1BB7.2010101@netwok.org>
Message-ID: <AANLkTinL_HXTntoD2VnAF0OtPf3Od=YVDGmZG=_hMTir@mail.gmail.com>

On Thu, Aug 19, 2010 at 9:55 PM, ?ric Araujo <merwok at netwok.org> wrote:
> Thanks for the replies.
>
> The dev FAQ is clear about regular use, it tells about the
> svnmerge-commit-message too, and people in #python-dev have told me that
> the merge order is py3k > 3.1, py3k > 2.7. My problem here is that I
> committed r84190 in 3.1 manually, but it should have been an svnmerge of
> r84187. So my question is: Do I have to svnmerge block -r84187 in 3.1?

Better to do "svnmerge merge --record-only -r84187".

(I have another request for the dev FAQ - could we get an FAQ entry
about how to update the FAQ itself? I usually just post here in the
hopes that someone will fix it, but we should be able to do better
than that. People have told me many times in the past how it actually
gets updated, but it never sticks in my memory).

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From ncoghlan at gmail.com  Thu Aug 19 15:34:00 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 19 Aug 2010 23:34:00 +1000
Subject: [Python-Dev] [Python-checkins] r84190 -
	python/branches/release31-maint/Doc/library/stdtypes.rst
In-Reply-To: <4C6D1CFA.6050601@trueblade.com>
References: <20100818224207.2A126EE981@mail.python.org>
	<4C6C630C.3000603@netwok.org>
	<AANLkTinbajdTneC-MKDU0rN3o6+w+asnDCsNx-HS6fP8@mail.gmail.com>
	<4C6D1BB7.2010101@netwok.org> <4C6D1CFA.6050601@trueblade.com>
Message-ID: <AANLkTinVaAZ0NUqjGukYd2D-0pf_7Tw=AO3P_Wuaf4Hf@mail.gmail.com>

On Thu, Aug 19, 2010 at 10:00 PM, Eric Smith <eric at trueblade.com> wrote:
>> Oh, this has to be done for every commit? I have for example fixed typos
>> in 3.x that don?t apply to 2.7, so I have to block them?
>
> I don't know that this matters, since I don't think anyone's doing mass
> merges in this direction. I tend to do it just for my own bookkeeping
> purposes, though.

This is probably a self-fulfilling prophecy. I know my last few
feature commits, I've moved on to the next feature I wanted to
implement rather than blocking the feature from 2.7 and 3.1.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From g.brandl at gmx.net  Thu Aug 19 17:28:19 2010
From: g.brandl at gmx.net (Georg Brandl)
Date: Thu, 19 Aug 2010 17:28:19 +0200
Subject: [Python-Dev] [Python-checkins] r84190 -
	python/branches/release31-maint/Doc/library/stdtypes.rst
In-Reply-To: <AANLkTinL_HXTntoD2VnAF0OtPf3Od=YVDGmZG=_hMTir@mail.gmail.com>
References: <20100818224207.2A126EE981@mail.python.org>	<4C6C630C.3000603@netwok.org>	<AANLkTinbajdTneC-MKDU0rN3o6+w+asnDCsNx-HS6fP8@mail.gmail.com>	<4C6D1BB7.2010101@netwok.org>
	<AANLkTinL_HXTntoD2VnAF0OtPf3Od=YVDGmZG=_hMTir@mail.gmail.com>
Message-ID: <i4jiir$54k$1@dough.gmane.org>

Am 19.08.2010 15:32, schrieb Nick Coghlan:
> On Thu, Aug 19, 2010 at 9:55 PM, ?ric Araujo <merwok at netwok.org> wrote:
>> Thanks for the replies.
>>
>> The dev FAQ is clear about regular use, it tells about the
>> svnmerge-commit-message too, and people in #python-dev have told me that
>> the merge order is py3k > 3.1, py3k > 2.7. My problem here is that I
>> committed r84190 in 3.1 manually, but it should have been an svnmerge of
>> r84187. So my question is: Do I have to svnmerge block -r84187 in 3.1?
> 
> Better to do "svnmerge merge --record-only -r84187".
> 
> (I have another request for the dev FAQ - could we get an FAQ entry
> about how to update the FAQ itself? I usually just post here in the
> hopes that someone will fix it, but we should be able to do better
> than that. People have told me many times in the past how it actually
> gets updated, but it never sticks in my memory).

Once we switch to SVN, the FAQ will get moved to its own repository and
be independent of the rest of the python.org website.

Until then, you need pydotorg commit privs and update it like other
pages on python.org

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.


From timothyjkinney at gmail.com  Thu Aug 19 08:11:17 2010
From: timothyjkinney at gmail.com (Timothy Kinney)
Date: Thu, 19 Aug 2010 01:11:17 -0500
Subject: [Python-Dev] Possible bug in randint when importing pylab?
Message-ID: <AANLkTimuev97TwQhcKfXS_6TnVeViJqt49Co+NyBzhn2@mail.gmail.com>

I am getting some unexpected behavior in Python 2.6.4 on a WinXP SP3 box.

If I run the following:

[code]
from pylab import randint

for s in range(100):
    print randint(0,1)
[/code]

I get 100 zeroes.

If I import randint from random instead, I get the expected behavior
of a random distribution of 1s and 0s.

I found this by importing * from pylab after importing randint from random.

What is going on? Is pylab's randint function broken somehow? Could
this be due to installing scipy into a 2.6 environment when it was
designed for the 2.5 environment?

cinead

From amauryfa at gmail.com  Thu Aug 19 18:02:21 2010
From: amauryfa at gmail.com (Amaury Forgeot d'Arc)
Date: Thu, 19 Aug 2010 18:02:21 +0200
Subject: [Python-Dev] Possible bug in randint when importing pylab?
In-Reply-To: <AANLkTimuev97TwQhcKfXS_6TnVeViJqt49Co+NyBzhn2@mail.gmail.com>
References: <AANLkTimuev97TwQhcKfXS_6TnVeViJqt49Co+NyBzhn2@mail.gmail.com>
Message-ID: <AANLkTi=U5-+JKYDeDL5pDKK0XHSShfiopXJZ6e6BMoAU@mail.gmail.com>

Hi,

2010/8/19 Timothy Kinney <timothyjkinney at gmail.com>:
> I am getting some unexpected behavior in Python 2.6.4 on a WinXP SP3 box.

This mailing list is for development *of* python, not about
development *with* python.
Your question should be directed to the comp.lang.python newsgroup, or
the python-list mailing list.

In any case, reading the documentation of both functions should answer
your question.

-- 
Amaury Forgeot d'Arc

From cournape at gmail.com  Thu Aug 19 18:15:26 2010
From: cournape at gmail.com (David Cournapeau)
Date: Fri, 20 Aug 2010 01:15:26 +0900
Subject: [Python-Dev] Possible bug in randint when importing pylab?
In-Reply-To: <AANLkTi=U5-+JKYDeDL5pDKK0XHSShfiopXJZ6e6BMoAU@mail.gmail.com>
References: <AANLkTimuev97TwQhcKfXS_6TnVeViJqt49Co+NyBzhn2@mail.gmail.com>
	<AANLkTi=U5-+JKYDeDL5pDKK0XHSShfiopXJZ6e6BMoAU@mail.gmail.com>
Message-ID: <AANLkTi=0Wb7W0q1PTnQVKpvhTYyJOwVGgu2FXzjkj_cm@mail.gmail.com>

On Fri, Aug 20, 2010 at 1:02 AM, Amaury Forgeot d'Arc
<amauryfa at gmail.com> wrote:
> Hi,
>
> 2010/8/19 Timothy Kinney <timothyjkinney at gmail.com>:
>> I am getting some unexpected behavior in Python 2.6.4 on a WinXP SP3 box.
>
> This mailing list is for development *of* python, not about
> development *with* python.
> Your question should be directed to the comp.lang.python newsgroup, or
> the python-list mailing list.

actually, the numpy and/or matplotlib ML would be even better in that case :)

David

From solipsis at pitrou.net  Thu Aug 19 19:01:42 2010
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Thu, 19 Aug 2010 19:01:42 +0200
Subject: [Python-Dev] [Python-checkins] r84190 -
 python/branches/release31-maint/Doc/library/stdtypes.rst
References: <20100818224207.2A126EE981@mail.python.org>
	<4C6C630C.3000603@netwok.org>
	<AANLkTinbajdTneC-MKDU0rN3o6+w+asnDCsNx-HS6fP8@mail.gmail.com>
	<4C6D1BB7.2010101@netwok.org>
	<AANLkTinL_HXTntoD2VnAF0OtPf3Od=YVDGmZG=_hMTir@mail.gmail.com>
	<i4jiir$54k$1@dough.gmane.org>
Message-ID: <20100819190142.39b01998@pitrou.net>

On Thu, 19 Aug 2010 17:28:19 +0200
Georg Brandl <g.brandl at gmx.net> wrote:
> Am 19.08.2010 15:32, schrieb Nick Coghlan:
> > On Thu, Aug 19, 2010 at 9:55 PM, ?ric Araujo <merwok at netwok.org> wrote:
> >> Thanks for the replies.
> >>
> >> The dev FAQ is clear about regular use, it tells about the
> >> svnmerge-commit-message too, and people in #python-dev have told me that
> >> the merge order is py3k > 3.1, py3k > 2.7. My problem here is that I
> >> committed r84190 in 3.1 manually, but it should have been an svnmerge of
> >> r84187. So my question is: Do I have to svnmerge block -r84187 in 3.1?
> > 
> > Better to do "svnmerge merge --record-only -r84187".
> > 
> > (I have another request for the dev FAQ - could we get an FAQ entry
> > about how to update the FAQ itself? I usually just post here in the
> > hopes that someone will fix it, but we should be able to do better
> > than that. People have told me many times in the past how it actually
> > gets updated, but it never sticks in my memory).
> 
> Once we switch to SVN,

You mean switch to Mercurial?



From solipsis at pitrou.net  Thu Aug 19 19:15:15 2010
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Thu, 19 Aug 2010 19:15:15 +0200
Subject: [Python-Dev] r84204 - in python/branches/py3k/Lib: os.py
	test/test_os.py
References: <20100819171019.2B677EE9AF@mail.python.org>
Message-ID: <20100819191515.6ab0b6cb@pitrou.net>

On Thu, 19 Aug 2010 19:10:19 +0200 (CEST)
victor.stinner <python-checkins at python.org> wrote:
> Author: victor.stinner
> Date: Thu Aug 19 19:10:18 2010
> New Revision: 84204
> 
> Log:
> Fix os.get_exec_path() (code and tests) for python -bb
> 
> Catch BytesWarning exceptions.

You should not catch warnings, but silence them using constructs
provided by the warnings module:

    with warnings.catch_warnings():
        warnings.simplefilter(ignore, BytesWarning)
        # the rest of your code


Otherwise you'll get buggy behaviour where e.g. env[b'PATH'] raises
BytesWarning because of an unicode key, but it would have succeeded
otherwise.

Regards

Antoine.



From benjamin at python.org  Thu Aug 19 19:41:53 2010
From: benjamin at python.org (Benjamin Peterson)
Date: Thu, 19 Aug 2010 12:41:53 -0500
Subject: [Python-Dev] [Python-checkins] r84190 -
	python/branches/release31-maint/Doc/library/stdtypes.rst
In-Reply-To: <i4jiir$54k$1@dough.gmane.org>
References: <20100818224207.2A126EE981@mail.python.org>
	<4C6C630C.3000603@netwok.org>
	<AANLkTinbajdTneC-MKDU0rN3o6+w+asnDCsNx-HS6fP8@mail.gmail.com>
	<4C6D1BB7.2010101@netwok.org>
	<AANLkTinL_HXTntoD2VnAF0OtPf3Od=YVDGmZG=_hMTir@mail.gmail.com>
	<i4jiir$54k$1@dough.gmane.org>
Message-ID: <AANLkTimFy6dnfCo_1Xj5WN5b6VCn1oka-X0M+j4JOr7+@mail.gmail.com>

2010/8/19 Georg Brandl <g.brandl at gmx.net>:
> Am 19.08.2010 15:32, schrieb Nick Coghlan:
>> On Thu, Aug 19, 2010 at 9:55 PM, ?ric Araujo <merwok at netwok.org> wrote:
>>> Thanks for the replies.
>>>
>>> The dev FAQ is clear about regular use, it tells about the
>>> svnmerge-commit-message too, and people in #python-dev have told me that
>>> the merge order is py3k > 3.1, py3k > 2.7. My problem here is that I
>>> committed r84190 in 3.1 manually, but it should have been an svnmerge of
>>> r84187. So my question is: Do I have to svnmerge block -r84187 in 3.1?
>>
>> Better to do "svnmerge merge --record-only -r84187".
>>
>> (I have another request for the dev FAQ - could we get an FAQ entry
>> about how to update the FAQ itself? I usually just post here in the
>> hopes that someone will fix it, but we should be able to do better
>> than that. People have told me many times in the past how it actually
>> gets updated, but it never sticks in my memory).
>
> Once we switch to SVN

Oh, good. I was really starting to hate CVS.



-- 
Regards,
Benjamin

From dickinsm at gmail.com  Thu Aug 19 19:48:44 2010
From: dickinsm at gmail.com (Mark Dickinson)
Date: Thu, 19 Aug 2010 18:48:44 +0100
Subject: [Python-Dev] Possible bug in randint when importing pylab?
In-Reply-To: <AANLkTimuev97TwQhcKfXS_6TnVeViJqt49Co+NyBzhn2@mail.gmail.com>
References: <AANLkTimuev97TwQhcKfXS_6TnVeViJqt49Co+NyBzhn2@mail.gmail.com>
Message-ID: <AANLkTimwHT+_nMPXhOkKXX6OOfqd24xNwcUCP=dEMVtS@mail.gmail.com>

On Thu, Aug 19, 2010 at 7:11 AM, Timothy Kinney
<timothyjkinney at gmail.com> wrote:
> I am getting some unexpected behavior in Python 2.6.4 on a WinXP SP3 box.
>
> If I run the following:
>
> [code]
> from pylab import randint
>
> for s in range(100):
> ? ?print randint(0,1)
> [/code]
>
> I get 100 zeroes.
>
> If I import randint from random instead, I get the expected behavior
> of a random distribution of 1s and 0s.
>
> I found this by importing * from pylab after importing randint from random.
>
> What is going on? Is pylab's randint function broken somehow? Could
> this be due to installing scipy into a 2.6 environment when it was
> designed for the 2.5 environment?

No;  this is by design.  The docstring for pylab's randint says:

    randint(low, high=None, size=None)

    Return random integers from `low` (inclusive) to `high` (exclusive).

IOW, it's similar to random.randrange in the stdlib.  In contrast,
random.randint *includes* both endpoints.  It's perhaps unfortunate
that random.randint and pylab.randint use different conventions, but
it's not a bug.

Mark

From victor.stinner at haypocalc.com  Thu Aug 19 22:07:09 2010
From: victor.stinner at haypocalc.com (Victor Stinner)
Date: Thu, 19 Aug 2010 22:07:09 +0200
Subject: [Python-Dev] [Python-checkins] r84209 -
	python/branches/py3k/Python/ast.c
In-Reply-To: <20100819174315.8B73CEEB92@mail.python.org>
References: <20100819174315.8B73CEEB92@mail.python.org>
Message-ID: <201008192207.09539.victor.stinner@haypocalc.com>

Le jeudi 19 ao?t 2010 19:43:15, amaury.forgeotdarc a ?crit :
> Author: amaury.forgeotdarc
> Date: Thu Aug 19 19:43:15 2010
> New Revision: 84209
> 
> Log:
> Check the return values for all functions returning an ast node.
> Failure to do it may result in strange error messages or even crashes,
> in admittedly convoluted cases that are normally syntax errors, like:
>     def f(*xx, __debug__): pass

Would it be possible to write tests for this change?

-- 
Victor Stinner
http://www.haypocalc.com/

From martin at v.loewis.de  Thu Aug 19 23:19:42 2010
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 19 Aug 2010 23:19:42 +0200
Subject: [Python-Dev] [Python-checkins] r84190
	-	python/branches/release31-maint/Doc/library/stdtypes.rst
In-Reply-To: <AANLkTinL_HXTntoD2VnAF0OtPf3Od=YVDGmZG=_hMTir@mail.gmail.com>
References: <20100818224207.2A126EE981@mail.python.org>	<4C6C630C.3000603@netwok.org>	<AANLkTinbajdTneC-MKDU0rN3o6+w+asnDCsNx-HS6fP8@mail.gmail.com>	<4C6D1BB7.2010101@netwok.org>
	<AANLkTinL_HXTntoD2VnAF0OtPf3Od=YVDGmZG=_hMTir@mail.gmail.com>
Message-ID: <4C6D9FEE.1080800@v.loewis.de>

> (I have another request for the dev FAQ - could we get an FAQ entry
> about how to update the FAQ itself? I usually just post here in the
> hopes that someone will fix it, but we should be able to do better
> than that. People have told me many times in the past how it actually
> gets updated, but it never sticks in my memory).

If you really *want* to update the FAQ yourself, I recommend you
do a pydotorg checkout _now_.

Ever since I did, I never forgot how to get it - simply because I
just kept the sandbox.

Regards,
Martin

From martin at v.loewis.de  Thu Aug 19 23:21:23 2010
From: martin at v.loewis.de (=?windows-1252?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 19 Aug 2010 23:21:23 +0200
Subject: [Python-Dev] [Python-checkins] r84190
	-	python/branches/release31-maint/Doc/library/stdtypes.rst
In-Reply-To: <AANLkTinzQeA2Djj5GyPZWKYwVnQxcLjzbgJsfo-GgDe9@mail.gmail.com>
References: <20100818224207.2A126EE981@mail.python.org>	<4C6C630C.3000603@netwok.org>	<AANLkTinbajdTneC-MKDU0rN3o6+w+asnDCsNx-HS6fP8@mail.gmail.com>	<4C6D1BB7.2010101@netwok.org>
	<4C6D1CFA.6050601@trueblade.com>
	<AANLkTinzQeA2Djj5GyPZWKYwVnQxcLjzbgJsfo-GgDe9@mail.gmail.com>
Message-ID: <4C6DA053.6040809@v.loewis.de>

> I do it every time myself, AFAIK it reduces the workload of people
> that are making sure all pending patches were applied.

Do we really have any such people still?

I thought they have all given up long ago.

Regards,
Martin

From merwok at netwok.org  Fri Aug 20 05:35:22 2010
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Fri, 20 Aug 2010 05:35:22 +0200
Subject: [Python-Dev] [Python-checkins] r84190
	-	python/branches/release31-maint/Doc/library/stdtypes.rst
In-Reply-To: <4C6D1BB7.2010101@netwok.org>
References: <20100818224207.2A126EE981@mail.python.org>	<4C6C630C.3000603@netwok.org>	<AANLkTinbajdTneC-MKDU0rN3o6+w+asnDCsNx-HS6fP8@mail.gmail.com>
	<4C6D1BB7.2010101@netwok.org>
Message-ID: <4C6DF7FA.5040303@netwok.org>

Thanks Eric for the reply and Nick for mentioning --record-only, this
was what I needed.

Tarek: I find the bug tracker simpler than svnmerge to keep track of
merges to be done. Of course, when there is no report, as for the typo
fixes I made, this doesn?t help. Oh well.

I?m going to do some Mercurial merges to feel better. In case the PSU
wants me to svnmerge block/record the few changes I committed without
using svnmerge afterward, tell them I won?t be far.

Regards, and thanks for helpi


From randall.walls at gmail.com  Thu Aug 19 16:48:58 2010
From: randall.walls at gmail.com (Randall Walls)
Date: Thu, 19 Aug 2010 10:48:58 -0400
Subject: [Python-Dev] IBM P-690 server looking for a home
Message-ID: <AANLkTimrX=4O5Zpi0dUvb_iUERwjaBUiW1tKCPqbnjXg@mail.gmail.com>

Greetings,

The company I work for has an IBM P-690 server that is in the process of
being retired. It is still a viable server, and has seen almost 0 use (it
was our failover machine). Unfortunately for us, this machine has little to
no resale value, and will probably be junked. I'd rather it go to a good
home, and having taken advantage of the work of the python development
community for a number of years (we use python extensively in system admin
and database work), I saw this as an opportunity to give back a little.

So, If anyone is interested in this machine, please let me know. We are
looking at perhaps a November time frame for when it will be removed from
our remote site. The P690 is no small machine, it is the size of a full rack
and has 32 Power4 processors in it and takes (I believe) 2 or 3 phase 220
Volt power. It weighs nearly a ton. We are running AIX5.3 on it, but I
believe that the machine is capable of running a PowerPC flavor of Linux as
well. This would make a great test machine for python HPC modules or as a
community box where developers could test their code against a PowerPC
architecture. It has lots of life left and I'd rather see it put to use then
thrown away.

Thanks,

-- 
Randall
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100819/5b14c466/attachment.html>

From trent at snakebite.org  Fri Aug 20 16:07:15 2010
From: trent at snakebite.org (Trent Nelson)
Date: Fri, 20 Aug 2010 10:07:15 -0400
Subject: [Python-Dev] IBM P-690 server looking for a home
In-Reply-To: <AANLkTimrX=4O5Zpi0dUvb_iUERwjaBUiW1tKCPqbnjXg@mail.gmail.com>
References: <AANLkTimrX=4O5Zpi0dUvb_iUERwjaBUiW1tKCPqbnjXg@mail.gmail.com>
Message-ID: <4C6E8C13.2050602@snakebite.org>

On 19-Aug-10 10:48 AM, Randall Walls wrote:
> Greetings,
>
> The company I work for has an IBM P-690 server that is in the process of
> being retired. It is still a viable server, and has seen almost 0 use
> (it was our failover machine). Unfortunately for us, this machine has
> little to no resale value, and will probably be junked. I'd rather it go
> to a good home, and having taken advantage of the work of the python
> development community for a number of years (we use python extensively
> in system admin and database work), I saw this as an opportunity to give
> back a little.
>
> So, If anyone is interested in this machine, please let me know. We are
> looking at perhaps a November time frame for when it will be removed
> from our remote site. The P690 is no small machine, it is the size of a
> full rack and has 32 Power4 processors in it and takes (I believe) 2 or
> 3 phase 220 Volt power. It weighs nearly a ton. We are running AIX5.3 on
> it, but I believe that the machine is capable of running a PowerPC
> flavor of Linux as well. This would make a great test machine for python
> HPC modules or as a community box where developers could test their code
> against a PowerPC architecture. It has lots of life left and I'd rather
> see it put to use then thrown away.

Snakebite[1]'s always got an eye out for free hardware, but dang, that's 
one chunky piece of kit.  I'll follow up in private.

(And yeah, I'm still working on Snakebite, for those that are 
interested.  Turns out hosting three racks of heavy-duty hardware in the 
corner room of a (graciously donated) science lab takes a bit longer 
than originally anticipated.  Who would have thought.)

Regards,

	Trent "no-news-is-good-news" Nelson.

[1]: http://www.snakebite.org/

From status at bugs.python.org  Fri Aug 20 18:08:28 2010
From: status at bugs.python.org (Python tracker)
Date: Fri, 20 Aug 2010 18:08:28 +0200 (CEST)
Subject: [Python-Dev] Summary of Python tracker Issues
Message-ID: <20100820160828.93570780D3@psf.upfronthosting.co.za>


ACTIVITY SUMMARY (2010-08-13 - 2010-08-20)
Python tracker at http://bugs.python.org/

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

Issues stats:
  open    2624 (+44)
  closed 18808 (+80)
  total  21432 (+63)

Open issues with patches: 1110 


Issues opened (44)
==================

#9189: Improve CFLAGS handling
http://bugs.python.org/issue9189  reopened by skrah

#9445: Fix undefined symbol errors on VS8.0 build
http://bugs.python.org/issue9445  reopened by amaury.forgeotdarc

#9591: kqueue not reporting EOF under certain circumstances
http://bugs.python.org/issue9591  opened by Volodymyr.Kostyrko

#9592: Limitations in objects returned by multiprocessing Pool
http://bugs.python.org/issue9592  opened by macfreek

#9594: typo on Mac/Makefile.in? s/pythonw/python/
http://bugs.python.org/issue9594  opened by srid

#9597: mac: Install 2to3 in /usr/local/bin
http://bugs.python.org/issue9597  opened by srid

#9598: untabify.py fails on files that contain non-ascii characters
http://bugs.python.org/issue9598  opened by belopolsky

#9601: ftplib should accept 250 on MKD
http://bugs.python.org/issue9601  opened by alphablue52

#9602: PyObject_AsCharBuffer() should only accept read-only objects
http://bugs.python.org/issue9602  opened by haypo

#9607: Test file 'test_keyword.py' submission for use with keyword.py
http://bugs.python.org/issue9607  opened by gregmalcolm

#9608: Re-phrase best way of using exceptions in doanddont.rst
http://bugs.python.org/issue9608  opened by flub

#9609: make cProfile multi-stack aware
http://bugs.python.org/issue9609  opened by krisvale

#9610: buildbot: uncaptured python exception (smtpd), but no failure 
http://bugs.python.org/issue9610  opened by flox

#9611: FileIO not 64-bit safe under Windows
http://bugs.python.org/issue9611  opened by pitrou

#9613: Python considers pid longs under 64-bit Windows
http://bugs.python.org/issue9613  opened by pitrou

#9614: _pickle is not entirely 64-bit safe
http://bugs.python.org/issue9614  opened by pitrou

#9617: Buffered IO shouldn't ignore incoming signals during a partial
http://bugs.python.org/issue9617  opened by pitrou

#9618: IDLE shell ignores all but first statement
http://bugs.python.org/issue9618  opened by cben

#9620: Python 2.7 IDLE fails on OS X 10.6
http://bugs.python.org/issue9620  opened by bpumali

#9621: Graphviz output for 2to3 fixer patterns
http://bugs.python.org/issue9621  opened by gmattbond

#9622: Allow to set profile/trace function globally
http://bugs.python.org/issue9622  opened by krisvale

#9624: 2755
http://bugs.python.org/issue9624  opened by Kartton

#9625: argparse: Problem with defaults for variable nargs
http://bugs.python.org/issue9625  opened by thesociable

#9628: runtests.sh -x doesn't work with more than two args (sed error
http://bugs.python.org/issue9628  opened by dmalcolm

#9630: Reencode filenames when setting the filesystem encoding
http://bugs.python.org/issue9630  opened by haypo

#9631: Python 2.7 installation issue for Linux gcc-4.1.0-3 (Fedora Co
http://bugs.python.org/issue9631  opened by spprakash

#9632: Remove sys.setfilesystemencoding()
http://bugs.python.org/issue9632  opened by haypo

#9633: pdb go stack up/down
http://bugs.python.org/issue9633  opened by Markus.Pr??ller

#9634: Add timeout parameter to Queue.join()
http://bugs.python.org/issue9634  opened by kdlucas

#9635: Add Py_BREAKPOINT and sys.breakpoint hooks
http://bugs.python.org/issue9635  opened by dmalcolm

#9637: docs do not say that urllib uses HTTP_PROXY
http://bugs.python.org/issue9637  opened by kirikaza

#9640: Improved doctest REPORT_*DIFFs with ELLIPSIS and/or NORMALIZE_
http://bugs.python.org/issue9640  opened by labrat

#9642: #ifdef and mbcs: don't check for	defined(HAVE_USABLE_WCHAR_T)
http://bugs.python.org/issue9642  opened by haypo

#9643: urllib2 - Basic,Digest Proxy Auth Handlers failure will give 4
http://bugs.python.org/issue9643  opened by orsenthil

#9644: PEP 383: os.statvfs() does not accept surrogateescape argument
http://bugs.python.org/issue9644  opened by baikie

#9645: PEP 383: os.pathconf() does not accept surrogateescape argumen
http://bugs.python.org/issue9645  opened by baikie

#9647: os.confstr() does not handle value changing length between cal
http://bugs.python.org/issue9647  opened by baikie

#9648: 2to3 doesn't convert "file" usage to an "open" equivalent
http://bugs.python.org/issue9648  opened by brian.curtin

#9649: wrong default for sort_keys in json module documentation
http://bugs.python.org/issue9649  opened by mdirolf

#9650: format codes in time.strptime docstrings
http://bugs.python.org/issue9650  opened by catherine

#706263: print raises exception when no console available
http://bugs.python.org/issue706263  reopened by amaury.forgeotdarc

#877121: configure detects incorrect compiler optimization
http://bugs.python.org/issue877121  reopened by r.david.murray

#749722: isinstance and weakref proxies.
http://bugs.python.org/issue749722  reopened by benjamin.peterson

#1545463: New-style classes fail to cleanup attributes
http://bugs.python.org/issue1545463  reopened by BreamoreBoy



Most recent 15 issues with no replies (15)
==========================================

#9650: format codes in time.strptime docstrings
http://bugs.python.org/issue9650

#9649: wrong default for sort_keys in json module documentation
http://bugs.python.org/issue9649

#9648: 2to3 doesn't convert "file" usage to an "open" equivalent
http://bugs.python.org/issue9648

#9647: os.confstr() does not handle value changing length between cal
http://bugs.python.org/issue9647

#9645: PEP 383: os.pathconf() does not accept surrogateescape argumen
http://bugs.python.org/issue9645

#9644: PEP 383: os.statvfs() does not accept surrogateescape argument
http://bugs.python.org/issue9644

#9643: urllib2 - Basic,Digest Proxy Auth Handlers failure will give 4
http://bugs.python.org/issue9643

#9637: docs do not say that urllib uses HTTP_PROXY
http://bugs.python.org/issue9637

#9625: argparse: Problem with defaults for variable nargs
http://bugs.python.org/issue9625

#9621: Graphviz output for 2to3 fixer patterns
http://bugs.python.org/issue9621

#9618: IDLE shell ignores all but first statement
http://bugs.python.org/issue9618

#9613: Python considers pid longs under 64-bit Windows
http://bugs.python.org/issue9613

#9609: make cProfile multi-stack aware
http://bugs.python.org/issue9609

#9608: Re-phrase best way of using exceptions in doanddont.rst
http://bugs.python.org/issue9608

#9607: Test file 'test_keyword.py' submission for use with keyword.py
http://bugs.python.org/issue9607



Most recent 15 issues waiting for review (15)
=============================================

#9649: wrong default for sort_keys in json module documentation
http://bugs.python.org/issue9649

#9645: PEP 383: os.pathconf() does not accept surrogateescape argumen
http://bugs.python.org/issue9645

#9644: PEP 383: os.statvfs() does not accept surrogateescape argument
http://bugs.python.org/issue9644

#9642: #ifdef and mbcs: don't check for	defined(HAVE_USABLE_WCHAR_T)
http://bugs.python.org/issue9642

#9640: Improved doctest REPORT_*DIFFs with ELLIPSIS and/or NORMALIZE_
http://bugs.python.org/issue9640

#9635: Add Py_BREAKPOINT and sys.breakpoint hooks
http://bugs.python.org/issue9635

#9632: Remove sys.setfilesystemencoding()
http://bugs.python.org/issue9632

#9630: Reencode filenames when setting the filesystem encoding
http://bugs.python.org/issue9630

#9628: runtests.sh -x doesn't work with more than two args (sed error
http://bugs.python.org/issue9628

#9622: Allow to set profile/trace function globally
http://bugs.python.org/issue9622

#9621: Graphviz output for 2to3 fixer patterns
http://bugs.python.org/issue9621

#9617: Buffered IO shouldn't ignore incoming signals during a partial
http://bugs.python.org/issue9617

#9614: _pickle is not entirely 64-bit safe
http://bugs.python.org/issue9614

#9609: make cProfile multi-stack aware
http://bugs.python.org/issue9609

#9608: Re-phrase best way of using exceptions in doanddont.rst
http://bugs.python.org/issue9608



Top 10 most discussed issues (10)
=================================

#9425: Rewrite import machinery to work with unicode paths
http://bugs.python.org/issue9425  24 msgs

#9573: importing a module that executes fork() raises RuntimeError
http://bugs.python.org/issue9573  12 msgs

#9622: Allow to set profile/trace function globally
http://bugs.python.org/issue9622   9 msgs

#4835: SIZEOF_SOCKET_T not defined
http://bugs.python.org/issue4835   8 msgs

#9601: ftplib should accept 250 on MKD
http://bugs.python.org/issue9601   8 msgs

#8739: Update to smtpd.py to RFC 5321
http://bugs.python.org/issue8739   7 msgs

#9611: FileIO not 64-bit safe under Windows
http://bugs.python.org/issue9611   7 msgs

#9634: Add timeout parameter to Queue.join()
http://bugs.python.org/issue9634   7 msgs

#1524938: PEP MemoryError with a lot of available memory gc not called
http://bugs.python.org/issue1524938   7 msgs

#9592: Limitations in objects returned by multiprocessing Pool
http://bugs.python.org/issue9592   6 msgs



Issues closed (80)
==================

#902061: pydoc insists upon producing file: URLs
http://bugs.python.org/issue902061  closed by BreamoreBoy

#1982: Feature: extend strftime to accept milliseconds
http://bugs.python.org/issue1982  closed by belopolsky

#2548: Undetected error in exception handling
http://bugs.python.org/issue2548  closed by BreamoreBoy

#3445: Ignore missing attributes in functools.update_wrapper
http://bugs.python.org/issue3445  closed by ncoghlan

#3488: Provide compress/uncompress functions on the gzip module
http://bugs.python.org/issue3488  closed by pitrou

#5127: Use Py_UCS4 instead of Py_UNICODE in unicodectype.c
http://bugs.python.org/issue5127  closed by amaury.forgeotdarc

#5737: add Solaris errnos
http://bugs.python.org/issue5737  closed by pitrou

#5867: No way to create an abstract classmethod
http://bugs.python.org/issue5867  closed by benjamin.peterson

#6724: r74463 causes failures in test_xmlrpc
http://bugs.python.org/issue6724  closed by r.david.murray

#7647: Add statvfs flags to the posix module
http://bugs.python.org/issue7647  closed by akuchling

#8622: Add PYTHONFSENCODING environment variable
http://bugs.python.org/issue8622  closed by haypo

#8669: lack of bdist_rpm module raises error on 'setup.py --help-comm
http://bugs.python.org/issue8669  closed by eric.araujo

#8807: poplib should support SSL contexts
http://bugs.python.org/issue8807  closed by giampaolo.rodola

#8857: socket.getaddrinfo needs tests
http://bugs.python.org/issue8857  closed by giampaolo.rodola

#8866: socket.getaddrinfo() should support keyword arguments
http://bugs.python.org/issue8866  closed by giampaolo.rodola

#8983: Docstrings should refer to help(name), not name.__doc__
http://bugs.python.org/issue8983  closed by belopolsky

#9147: dis.show_code() variant that accepts source strings (and retur
http://bugs.python.org/issue9147  closed by ncoghlan

#9203: Use computed gotos by default
http://bugs.python.org/issue9203  closed by pitrou

#9433: regrtest.py -j 2 doesn't work on Windows: remove close_fds=Tru
http://bugs.python.org/issue9433  closed by pitrou

#9542: Create PyUnicode_FSDecoder() function
http://bugs.python.org/issue9542  closed by haypo

#9560: platform.py: use -b option for file	command	in	_syscmd_file()
http://bugs.python.org/issue9560  closed by haypo

#9567: Add attribute pointing to wrapped function in functools.update
http://bugs.python.org/issue9567  closed by ncoghlan

#9569: Add tests for posix.mknod() and posix.mkfifo()
http://bugs.python.org/issue9569  closed by benjamin.peterson

#9587: unittest.assertRaises() return the raised exception
http://bugs.python.org/issue9587  closed by michael.foord

#9588: Add sys.executable to test_subprocessing.CommandsWithSpaces sh
http://bugs.python.org/issue9588  closed by brian.curtin

#9589: test_heapq: AttributeError: 'int' object has no attribute 'pop
http://bugs.python.org/issue9589  closed by pitrou

#9590: __init__ TypeError reverses expected vs received args
http://bugs.python.org/issue9590  closed by flox

#9593: utf8 codec readlines error after "\x85 "
http://bugs.python.org/issue9593  closed by pitrou

#9595: PC/getpathp.c unused?
http://bugs.python.org/issue9595  closed by pitrou

#9596: PC/getpathp.c unused?
http://bugs.python.org/issue9596  closed by pitrou

#9599: Add PySys_FormatStdout and PySys_FormatStderr functions
http://bugs.python.org/issue9599  closed by haypo

#9600: multiprocessing Pool instantiation crashes on 64 bit 2.6.6rc1 
http://bugs.python.org/issue9600  closed by brian.curtin

#9603: os.ttyname() and os.ctermid() don't decode result according to
http://bugs.python.org/issue9603  closed by haypo

#9604: os.initgroups() doesn't accept PEP 383 usernames returned by p
http://bugs.python.org/issue9604  closed by haypo

#9605: os.getlogin() should use PEP 383 decoding to match the pwd mod
http://bugs.python.org/issue9605  closed by haypo

#9606: logging filter is not applied to messages from descendant logg
http://bugs.python.org/issue9606  closed by vinay.sajip

#9612: setobject.c warnings under 64-bit Windows
http://bugs.python.org/issue9612  closed by pitrou

#9615: Building SSL fails under 64-bit Windows
http://bugs.python.org/issue9615  closed by pitrou

#9616: copy.deepcopy() copying pointers from a dict/dict/list, should
http://bugs.python.org/issue9616  closed by nharkins

#9619: test_ssl freezes
http://bugs.python.org/issue9619  closed by richard

#9623: test_site.py has a couple of stray self.assertTrue calls that 
http://bugs.python.org/issue9623  closed by ezio.melotti

#9626: OderedDict.viewitems() does not preserve item order
http://bugs.python.org/issue9626  closed by rhettinger

#9627: Regrtest failed to clean up temporary directory
http://bugs.python.org/issue9627  closed by ncoghlan

#9629: SIZEOF_SOCKET_T used in longobject.h but undefined
http://bugs.python.org/issue9629  closed by dmalcolm

#9636: BytesWarning annoyances {'key': 'value'}.get(b'key')
http://bugs.python.org/issue9636  closed by pitrou

#9638: remove dead code from py3k imaplib
http://bugs.python.org/issue9638  closed by orsenthil

#9639: urllib2's AbstractBasicAuthHandler is limited to 6 requests
http://bugs.python.org/issue9639  closed by orsenthil

#9641: httplib/ftplib: timeout parameter not applied correctly
http://bugs.python.org/issue9641  closed by anders.sandvig

#9646: Mutable default function parameter warning
http://bugs.python.org/issue9646  closed by benjamin.peterson

#748843: Let Email.Utils.parsedate use last 3 timetuple items
http://bugs.python.org/issue748843  closed by BreamoreBoy

#761888: popen2.Popen3 and popen2.Popen4 leaks filedescriptors
http://bugs.python.org/issue761888  closed by BreamoreBoy

#502236: Asynchronous exceptions between threads
http://bugs.python.org/issue502236  closed by akuchling

#1055864: HTMLParser not compliant to XHTML spec
http://bugs.python.org/issue1055864  closed by fdrake

#731991: find correct socklen_t type
http://bugs.python.org/issue731991  closed by BreamoreBoy

#798520: os.popen with invalid mode differs on Windows and POSIX
http://bugs.python.org/issue798520  closed by BreamoreBoy

#834461: simple bsddb interface potential for deadlock with threads
http://bugs.python.org/issue834461  closed by BreamoreBoy

#1018492: Solaris: reentrancy issues
http://bugs.python.org/issue1018492  closed by BreamoreBoy

#999444: compiler module doesn't support unicode characters in laiter
http://bugs.python.org/issue999444  closed by BreamoreBoy

#868571: HTTPResponse.read(amt) fails when response length is UNKNOWN
http://bugs.python.org/issue868571  closed by BreamoreBoy

#822005: Carbon.CarbonEvt.ReceiveNextEvent args wrong
http://bugs.python.org/issue822005  closed by BreamoreBoy

#1282647: socket.getaddrinfo() bug for IPv6 enabled platforms
http://bugs.python.org/issue1282647  closed by giampaolo.rodola

#672656: securing pydoc server
http://bugs.python.org/issue672656  closed by orsenthil

#805194: Inappropriate error received using socket timeout
http://bugs.python.org/issue805194  closed by pitrou

#904498: threading docs, start error should be specified
http://bugs.python.org/issue904498  closed by BreamoreBoy

#1021318: PyThreadState_Next not thread safe?
http://bugs.python.org/issue1021318  closed by BreamoreBoy

#836035: strftime month name is encoded somehow
http://bugs.python.org/issue836035  closed by BreamoreBoy

#775321: plistlib error handling
http://bugs.python.org/issue775321  closed by BreamoreBoy

#1104021: wishlist: os.feed_urandom(input)
http://bugs.python.org/issue1104021  closed by BreamoreBoy

#678250: test_mmap failling on AIX
http://bugs.python.org/issue678250  closed by BreamoreBoy

#515073: subtypable weak references
http://bugs.python.org/issue515073  closed by BreamoreBoy

#1007223: SGI (IRIX6.5.24) Problems building nismodule.c
http://bugs.python.org/issue1007223  closed by BreamoreBoy

#1104249: configure doesn't set up CFLAGS properly
http://bugs.python.org/issue1104249  closed by skrah

#713169: test_pty fails on HP-UX and AIX when run after test_openpty
http://bugs.python.org/issue713169  closed by BreamoreBoy

#877904: freeze: problems excluding site
http://bugs.python.org/issue877904  closed by BreamoreBoy

#1020188: Use Py_CLEAR where necessary to avoid crashes
http://bugs.python.org/issue1020188  closed by mwh

#762920: API Functions for PyArray
http://bugs.python.org/issue762920  closed by BreamoreBoy

#618023: imap handler in urllib(2)
http://bugs.python.org/issue618023  closed by BreamoreBoy

#683938: HTMLParser attribute parsing bug
http://bugs.python.org/issue683938  closed by BreamoreBoy

#816059: popen2 work, fixes bugs 768649 and 761888
http://bugs.python.org/issue816059  closed by BreamoreBoy

#1113244: Please add do-while guard to Py_DECREF etc.
http://bugs.python.org/issue1113244  closed by benjamin.peterson

From florent.xicluna at gmail.com  Fri Aug 20 19:49:10 2010
From: florent.xicluna at gmail.com (Florent Xicluna)
Date: Fri, 20 Aug 2010 19:49:10 +0200
Subject: [Python-Dev] Summary of Python tracker Issues
In-Reply-To: <20100820160828.93570780D3@psf.upfronthosting.co.za>
References: <20100820160828.93570780D3@psf.upfronthosting.co.za>
Message-ID: <AANLkTimeXWM9e8SH9W+Nr3A78grTAO9eYkPq5ZPHnbxf@mail.gmail.com>

And Now For Something Completely Different...

  http://code.google.com/p/bbreport/wiki/PythonBuildbotReport

The buildbot failures and tracker issues are listed in 3 tables:

?- *New failures* : failures which are not associated with an issue in
the tracker

?- *Known issues* : failures which are (probably) linked with an existing issue
?? (the association [failure] <--> [issue] is based on regexp rules)

?- *No recent failure* : these issues are no longer reported on recent
builds. Either the problem is fixed, or the failure is elusive.

The page is hosted on Google Code. Victor hosts a cron job which
recalculates and upload the JSON data.
Currently, the report is uploaded every hour.

Regards,

-- 
Florent Xicluna

2010/8/20 Python tracker
>
> ACTIVITY SUMMARY (2010-08-13 - 2010-08-20)
> Python tracker at http://bugs.python.org/
>
> To view or respond to any of the issues listed below, click on the issue.
> Do NOT respond to this message.
>
> Issues stats:
> ?open ? ?2624 (+44)
> ?closed 18808 (+80)
> ?total ?21432 (+63)
>
> Open issues with patches: 1110
>
>
> Issues opened (44)
> ==================
>
> #9189: Improve CFLAGS handling
> http://bugs.python.org/issue9189 ?reopened by skrah
>
> #9445: Fix undefined symbol errors on VS8.0 build
> http://bugs.python.org/issue9445 ?reopened by amaury.forgeotdarc
>
> #9591: kqueue not reporting EOF under certain circumstances
> http://bugs.python.org/issue9591 ?opened by Volodymyr.Kostyrko
>
> #9592: Limitations in objects returned by multiprocessing Pool
> http://bugs.python.org/issue9592 ?opened by macfreek
>
> #9594: typo on Mac/Makefile.in? s/pythonw/python/
> http://bugs.python.org/issue9594 ?opened by srid
>
> #9597: mac: Install 2to3 in /usr/local/bin
> http://bugs.python.org/issue9597 ?opened by srid
>
> #9598: untabify.py fails on files that contain non-ascii characters
> http://bugs.python.org/issue9598 ?opened by belopolsky
>
> #9601: ftplib should accept 250 on MKD
> http://bugs.python.org/issue9601 ?opened by alphablue52
>
> #9602: PyObject_AsCharBuffer() should only accept read-only objects
> http://bugs.python.org/issue9602 ?opened by haypo
>
> #9607: Test file 'test_keyword.py' submission for use with keyword.py
> http://bugs.python.org/issue9607 ?opened by gregmalcolm
>
> #9608: Re-phrase best way of using exceptions in doanddont.rst
> http://bugs.python.org/issue9608 ?opened by flub
>
> #9609: make cProfile multi-stack aware
> http://bugs.python.org/issue9609 ?opened by krisvale
>
> #9610: buildbot: uncaptured python exception (smtpd), but no failure
> http://bugs.python.org/issue9610 ?opened by flox
>
> #9611: FileIO not 64-bit safe under Windows
> http://bugs.python.org/issue9611 ?opened by pitrou
>
> #9613: Python considers pid longs under 64-bit Windows
> http://bugs.python.org/issue9613 ?opened by pitrou
>
> #9614: _pickle is not entirely 64-bit safe
> http://bugs.python.org/issue9614 ?opened by pitrou
>
> #9617: Buffered IO shouldn't ignore incoming signals during a partial
> http://bugs.python.org/issue9617 ?opened by pitrou
>
> #9618: IDLE shell ignores all but first statement
> http://bugs.python.org/issue9618 ?opened by cben
>
> #9620: Python 2.7 IDLE fails on OS X 10.6
> http://bugs.python.org/issue9620 ?opened by bpumali
>
> #9621: Graphviz output for 2to3 fixer patterns
> http://bugs.python.org/issue9621 ?opened by gmattbond
>
> #9622: Allow to set profile/trace function globally
> http://bugs.python.org/issue9622 ?opened by krisvale
>
> #9624: 2755
> http://bugs.python.org/issue9624 ?opened by Kartton
>
> #9625: argparse: Problem with defaults for variable nargs
> http://bugs.python.org/issue9625 ?opened by thesociable
>
> #9628: runtests.sh -x doesn't work with more than two args (sed error
> http://bugs.python.org/issue9628 ?opened by dmalcolm
>
> #9630: Reencode filenames when setting the filesystem encoding
> http://bugs.python.org/issue9630 ?opened by haypo
>
> #9631: Python 2.7 installation issue for Linux gcc-4.1.0-3 (Fedora Co
> http://bugs.python.org/issue9631 ?opened by spprakash
>
> #9632: Remove sys.setfilesystemencoding()
> http://bugs.python.org/issue9632 ?opened by haypo
>
> #9633: pdb go stack up/down
> http://bugs.python.org/issue9633 ?opened by Markus.Pr?ller
>
> #9634: Add timeout parameter to Queue.join()
> http://bugs.python.org/issue9634 ?opened by kdlucas
>
> #9635: Add Py_BREAKPOINT and sys.breakpoint hooks
> http://bugs.python.org/issue9635 ?opened by dmalcolm
>
> #9637: docs do not say that urllib uses HTTP_PROXY
> http://bugs.python.org/issue9637 ?opened by kirikaza
>
> #9640: Improved doctest REPORT_*DIFFs with ELLIPSIS and/or NORMALIZE_
> http://bugs.python.org/issue9640 ?opened by labrat
>
> #9642: #ifdef and mbcs: don't check for defined(HAVE_USABLE_WCHAR_T)
> http://bugs.python.org/issue9642 ?opened by haypo
>
> #9643: urllib2 - Basic,Digest Proxy Auth Handlers failure will give 4
> http://bugs.python.org/issue9643 ?opened by orsenthil
>
> #9644: PEP 383: os.statvfs() does not accept surrogateescape argument
> http://bugs.python.org/issue9644 ?opened by baikie
>
> #9645: PEP 383: os.pathconf() does not accept surrogateescape argumen
> http://bugs.python.org/issue9645 ?opened by baikie
>
> #9647: os.confstr() does not handle value changing length between cal
> http://bugs.python.org/issue9647 ?opened by baikie
>
> #9648: 2to3 doesn't convert "file" usage to an "open" equivalent
> http://bugs.python.org/issue9648 ?opened by brian.curtin
>
> #9649: wrong default for sort_keys in json module documentation
> http://bugs.python.org/issue9649 ?opened by mdirolf
>
> #9650: format codes in time.strptime docstrings
> http://bugs.python.org/issue9650 ?opened by catherine
>
> #706263: print raises exception when no console available
> http://bugs.python.org/issue706263 ?reopened by amaury.forgeotdarc
>
> #877121: configure detects incorrect compiler optimization
> http://bugs.python.org/issue877121 ?reopened by r.david.murray
>
> #749722: isinstance and weakref proxies.
> http://bugs.python.org/issue749722 ?reopened by benjamin.peterson
>
> #1545463: New-style classes fail to cleanup attributes
> http://bugs.python.org/issue1545463 ?reopened by BreamoreBoy
>
>
>
> Most recent 15 issues with no replies (15)
> ==========================================
>
> #9650: format codes in time.strptime docstrings
> http://bugs.python.org/issue9650
>
> #9649: wrong default for sort_keys in json module documentation
> http://bugs.python.org/issue9649
>
> #9648: 2to3 doesn't convert "file" usage to an "open" equivalent
> http://bugs.python.org/issue9648
>
> #9647: os.confstr() does not handle value changing length between cal
> http://bugs.python.org/issue9647
>
> #9645: PEP 383: os.pathconf() does not accept surrogateescape argumen
> http://bugs.python.org/issue9645
>
> #9644: PEP 383: os.statvfs() does not accept surrogateescape argument
> http://bugs.python.org/issue9644
>
> #9643: urllib2 - Basic,Digest Proxy Auth Handlers failure will give 4
> http://bugs.python.org/issue9643
>
> #9637: docs do not say that urllib uses HTTP_PROXY
> http://bugs.python.org/issue9637
>
> #9625: argparse: Problem with defaults for variable nargs
> http://bugs.python.org/issue9625
>
> #9621: Graphviz output for 2to3 fixer patterns
> http://bugs.python.org/issue9621
>
> #9618: IDLE shell ignores all but first statement
> http://bugs.python.org/issue9618
>
> #9613: Python considers pid longs under 64-bit Windows
> http://bugs.python.org/issue9613
>
> #9609: make cProfile multi-stack aware
> http://bugs.python.org/issue9609
>
> #9608: Re-phrase best way of using exceptions in doanddont.rst
> http://bugs.python.org/issue9608
>
> #9607: Test file 'test_keyword.py' submission for use with keyword.py
> http://bugs.python.org/issue9607
>
>
>
> Most recent 15 issues waiting for review (15)
> =============================================
>
> #9649: wrong default for sort_keys in json module documentation
> http://bugs.python.org/issue9649
>
> #9645: PEP 383: os.pathconf() does not accept surrogateescape argumen
> http://bugs.python.org/issue9645
>
> #9644: PEP 383: os.statvfs() does not accept surrogateescape argument
> http://bugs.python.org/issue9644
>
> #9642: #ifdef and mbcs: don't check for defined(HAVE_USABLE_WCHAR_T)
> http://bugs.python.org/issue9642
>
> #9640: Improved doctest REPORT_*DIFFs with ELLIPSIS and/or NORMALIZE_
> http://bugs.python.org/issue9640
>
> #9635: Add Py_BREAKPOINT and sys.breakpoint hooks
> http://bugs.python.org/issue9635
>
> #9632: Remove sys.setfilesystemencoding()
> http://bugs.python.org/issue9632
>
> #9630: Reencode filenames when setting the filesystem encoding
> http://bugs.python.org/issue9630
>
> #9628: runtests.sh -x doesn't work with more than two args (sed error
> http://bugs.python.org/issue9628
>
> #9622: Allow to set profile/trace function globally
> http://bugs.python.org/issue9622
>
> #9621: Graphviz output for 2to3 fixer patterns
> http://bugs.python.org/issue9621
>
> #9617: Buffered IO shouldn't ignore incoming signals during a partial
> http://bugs.python.org/issue9617
>
> #9614: _pickle is not entirely 64-bit safe
> http://bugs.python.org/issue9614
>
> #9609: make cProfile multi-stack aware
> http://bugs.python.org/issue9609
>
> #9608: Re-phrase best way of using exceptions in doanddont.rst
> http://bugs.python.org/issue9608
>
>
>
> Top 10 most discussed issues (10)
> =================================
>
> #9425: Rewrite import machinery to work with unicode paths
> http://bugs.python.org/issue9425 ?24 msgs
>
> #9573: importing a module that executes fork() raises RuntimeError
> http://bugs.python.org/issue9573 ?12 msgs
>
> #9622: Allow to set profile/trace function globally
> http://bugs.python.org/issue9622 ? 9 msgs
>
> #4835: SIZEOF_SOCKET_T not defined
> http://bugs.python.org/issue4835 ? 8 msgs
>
> #9601: ftplib should accept 250 on MKD
> http://bugs.python.org/issue9601 ? 8 msgs
>
> #8739: Update to smtpd.py to RFC 5321
> http://bugs.python.org/issue8739 ? 7 msgs
>
> #9611: FileIO not 64-bit safe under Windows
> http://bugs.python.org/issue9611 ? 7 msgs
>
> #9634: Add timeout parameter to Queue.join()
> http://bugs.python.org/issue9634 ? 7 msgs
>
> #1524938: PEP MemoryError with a lot of available memory gc not called
> http://bugs.python.org/issue1524938 ? 7 msgs
>
> #9592: Limitations in objects returned by multiprocessing Pool
> http://bugs.python.org/issue9592 ? 6 msgs
>
>
>
> Issues closed (80)
> ==================
>
> #902061: pydoc insists upon producing file: URLs
> http://bugs.python.org/issue902061 ?closed by BreamoreBoy
>
> #1982: Feature: extend strftime to accept milliseconds
> http://bugs.python.org/issue1982 ?closed by belopolsky
>
> #2548: Undetected error in exception handling
> http://bugs.python.org/issue2548 ?closed by BreamoreBoy
>
> #3445: Ignore missing attributes in functools.update_wrapper
> http://bugs.python.org/issue3445 ?closed by ncoghlan
>
> #3488: Provide compress/uncompress functions on the gzip module
> http://bugs.python.org/issue3488 ?closed by pitrou
>
> #5127: Use Py_UCS4 instead of Py_UNICODE in unicodectype.c
> http://bugs.python.org/issue5127 ?closed by amaury.forgeotdarc
>
> #5737: add Solaris errnos
> http://bugs.python.org/issue5737 ?closed by pitrou
>
> #5867: No way to create an abstract classmethod
> http://bugs.python.org/issue5867 ?closed by benjamin.peterson
>
> #6724: r74463 causes failures in test_xmlrpc
> http://bugs.python.org/issue6724 ?closed by r.david.murray
>
> #7647: Add statvfs flags to the posix module
> http://bugs.python.org/issue7647 ?closed by akuchling
>
> #8622: Add PYTHONFSENCODING environment variable
> http://bugs.python.org/issue8622 ?closed by haypo
>
> #8669: lack of bdist_rpm module raises error on 'setup.py --help-comm
> http://bugs.python.org/issue8669 ?closed by eric.araujo
>
> #8807: poplib should support SSL contexts
> http://bugs.python.org/issue8807 ?closed by giampaolo.rodola
>
> #8857: socket.getaddrinfo needs tests
> http://bugs.python.org/issue8857 ?closed by giampaolo.rodola
>
> #8866: socket.getaddrinfo() should support keyword arguments
> http://bugs.python.org/issue8866 ?closed by giampaolo.rodola
>
> #8983: Docstrings should refer to help(name), not name.__doc__
> http://bugs.python.org/issue8983 ?closed by belopolsky
>
> #9147: dis.show_code() variant that accepts source strings (and retur
> http://bugs.python.org/issue9147 ?closed by ncoghlan
>
> #9203: Use computed gotos by default
> http://bugs.python.org/issue9203 ?closed by pitrou
>
> #9433: regrtest.py -j 2 doesn't work on Windows: remove close_fds=Tru
> http://bugs.python.org/issue9433 ?closed by pitrou
>
> #9542: Create PyUnicode_FSDecoder() function
> http://bugs.python.org/issue9542 ?closed by haypo
>
> #9560: platform.py: use -b option for file ? ? ?command in ? ? ?_syscmd_file()
> http://bugs.python.org/issue9560 ?closed by haypo
>
> #9567: Add attribute pointing to wrapped function in functools.update
> http://bugs.python.org/issue9567 ?closed by ncoghlan
>
> #9569: Add tests for posix.mknod() and posix.mkfifo()
> http://bugs.python.org/issue9569 ?closed by benjamin.peterson
>
> #9587: unittest.assertRaises() return the raised exception
> http://bugs.python.org/issue9587 ?closed by michael.foord
>
> #9588: Add sys.executable to test_subprocessing.CommandsWithSpaces sh
> http://bugs.python.org/issue9588 ?closed by brian.curtin
>
> #9589: test_heapq: AttributeError: 'int' object has no attribute 'pop
> http://bugs.python.org/issue9589 ?closed by pitrou
>
> #9590: __init__ TypeError reverses expected vs received args
> http://bugs.python.org/issue9590 ?closed by flox
>
> #9593: utf8 codec readlines error after "\x85 "
> http://bugs.python.org/issue9593 ?closed by pitrou
>
> #9595: PC/getpathp.c unused?
> http://bugs.python.org/issue9595 ?closed by pitrou
>
> #9596: PC/getpathp.c unused?
> http://bugs.python.org/issue9596 ?closed by pitrou
>
> #9599: Add PySys_FormatStdout and PySys_FormatStderr functions
> http://bugs.python.org/issue9599 ?closed by haypo
>
> #9600: multiprocessing Pool instantiation crashes on 64 bit 2.6.6rc1
> http://bugs.python.org/issue9600 ?closed by brian.curtin
>
> #9603: os.ttyname() and os.ctermid() don't decode result according to
> http://bugs.python.org/issue9603 ?closed by haypo
>
> #9604: os.initgroups() doesn't accept PEP 383 usernames returned by p
> http://bugs.python.org/issue9604 ?closed by haypo
>
> #9605: os.getlogin() should use PEP 383 decoding to match the pwd mod
> http://bugs.python.org/issue9605 ?closed by haypo
>
> #9606: logging filter is not applied to messages from descendant logg
> http://bugs.python.org/issue9606 ?closed by vinay.sajip
>
> #9612: setobject.c warnings under 64-bit Windows
> http://bugs.python.org/issue9612 ?closed by pitrou
>
> #9615: Building SSL fails under 64-bit Windows
> http://bugs.python.org/issue9615 ?closed by pitrou
>
> #9616: copy.deepcopy() copying pointers from a dict/dict/list, should
> http://bugs.python.org/issue9616 ?closed by nharkins
>
> #9619: test_ssl freezes
> http://bugs.python.org/issue9619 ?closed by richard
>
> #9623: test_site.py has a couple of stray self.assertTrue calls that
> http://bugs.python.org/issue9623 ?closed by ezio.melotti
>
> #9626: OderedDict.viewitems() does not preserve item order
> http://bugs.python.org/issue9626 ?closed by rhettinger
>
> #9627: Regrtest failed to clean up temporary directory
> http://bugs.python.org/issue9627 ?closed by ncoghlan
>
> #9629: SIZEOF_SOCKET_T used in longobject.h but undefined
> http://bugs.python.org/issue9629 ?closed by dmalcolm
>
> #9636: BytesWarning annoyances {'key': 'value'}.get(b'key')
> http://bugs.python.org/issue9636 ?closed by pitrou
>
> #9638: remove dead code from py3k imaplib
> http://bugs.python.org/issue9638 ?closed by orsenthil
>
> #9639: urllib2's AbstractBasicAuthHandler is limited to 6 requests
> http://bugs.python.org/issue9639 ?closed by orsenthil
>
> #9641: httplib/ftplib: timeout parameter not applied correctly
> http://bugs.python.org/issue9641 ?closed by anders.sandvig
>
> #9646: Mutable default function parameter warning
> http://bugs.python.org/issue9646 ?closed by benjamin.peterson
>
> #748843: Let Email.Utils.parsedate use last 3 timetuple items
> http://bugs.python.org/issue748843 ?closed by BreamoreBoy
>
> #761888: popen2.Popen3 and popen2.Popen4 leaks filedescriptors
> http://bugs.python.org/issue761888 ?closed by BreamoreBoy
>
> #502236: Asynchronous exceptions between threads
> http://bugs.python.org/issue502236 ?closed by akuchling
>
> #1055864: HTMLParser not compliant to XHTML spec
> http://bugs.python.org/issue1055864 ?closed by fdrake
>
> #731991: find correct socklen_t type
> http://bugs.python.org/issue731991 ?closed by BreamoreBoy
>
> #798520: os.popen with invalid mode differs on Windows and POSIX
> http://bugs.python.org/issue798520 ?closed by BreamoreBoy
>
> #834461: simple bsddb interface potential for deadlock with threads
> http://bugs.python.org/issue834461 ?closed by BreamoreBoy
>
> #1018492: Solaris: reentrancy issues
> http://bugs.python.org/issue1018492 ?closed by BreamoreBoy
>
> #999444: compiler module doesn't support unicode characters in laiter
> http://bugs.python.org/issue999444 ?closed by BreamoreBoy
>
> #868571: HTTPResponse.read(amt) fails when response length is UNKNOWN
> http://bugs.python.org/issue868571 ?closed by BreamoreBoy
>
> #822005: Carbon.CarbonEvt.ReceiveNextEvent args wrong
> http://bugs.python.org/issue822005 ?closed by BreamoreBoy
>
> #1282647: socket.getaddrinfo() bug for IPv6 enabled platforms
> http://bugs.python.org/issue1282647 ?closed by giampaolo.rodola
>
> #672656: securing pydoc server
> http://bugs.python.org/issue672656 ?closed by orsenthil
>
> #805194: Inappropriate error received using socket timeout
> http://bugs.python.org/issue805194 ?closed by pitrou
>
> #904498: threading docs, start error should be specified
> http://bugs.python.org/issue904498 ?closed by BreamoreBoy
>
> #1021318: PyThreadState_Next not thread safe?
> http://bugs.python.org/issue1021318 ?closed by BreamoreBoy
>
> #836035: strftime month name is encoded somehow
> http://bugs.python.org/issue836035 ?closed by BreamoreBoy
>
> #775321: plistlib error handling
> http://bugs.python.org/issue775321 ?closed by BreamoreBoy
>
> #1104021: wishlist: os.feed_urandom(input)
> http://bugs.python.org/issue1104021 ?closed by BreamoreBoy
>
> #678250: test_mmap failling on AIX
> http://bugs.python.org/issue678250 ?closed by BreamoreBoy
>
> #515073: subtypable weak references
> http://bugs.python.org/issue515073 ?closed by BreamoreBoy
>
> #1007223: SGI (IRIX6.5.24) Problems building nismodule.c
> http://bugs.python.org/issue1007223 ?closed by BreamoreBoy
>
> #1104249: configure doesn't set up CFLAGS properly
> http://bugs.python.org/issue1104249 ?closed by skrah
>
> #713169: test_pty fails on HP-UX and AIX when run after test_openpty
> http://bugs.python.org/issue713169 ?closed by BreamoreBoy
>
> #877904: freeze: problems excluding site
> http://bugs.python.org/issue877904 ?closed by BreamoreBoy
>
> #1020188: Use Py_CLEAR where necessary to avoid crashes
> http://bugs.python.org/issue1020188 ?closed by mwh
>
> #762920: API Functions for PyArray
> http://bugs.python.org/issue762920 ?closed by BreamoreBoy
>
> #618023: imap handler in urllib(2)
> http://bugs.python.org/issue618023 ?closed by BreamoreBoy
>
> #683938: HTMLParser attribute parsing bug
> http://bugs.python.org/issue683938 ?closed by BreamoreBoy
>
> #816059: popen2 work, fixes bugs 768649 and 761888
> http://bugs.python.org/issue816059 ?closed by BreamoreBoy
>
> #1113244: Please add do-while guard to Py_DECREF etc.
> http://bugs.python.org/issue1113244 ?closed by benjamin.peterson
>

From victor.stinner at haypocalc.com  Sat Aug 21 00:47:46 2010
From: victor.stinner at haypocalc.com (Victor Stinner)
Date: Sat, 21 Aug 2010 00:47:46 +0200
Subject: [Python-Dev] Summary of Python tracker Issues
In-Reply-To: <AANLkTimeXWM9e8SH9W+Nr3A78grTAO9eYkPq5ZPHnbxf@mail.gmail.com>
References: <20100820160828.93570780D3@psf.upfronthosting.co.za>
	<AANLkTimeXWM9e8SH9W+Nr3A78grTAO9eYkPq5ZPHnbxf@mail.gmail.com>
Message-ID: <201008210047.46817.victor.stinner@haypocalc.com>

Le vendredi 20 ao?t 2010 19:49:10, vous avez ?crit :
> And Now For Something Completely Different...
> 
>   http://code.google.com/p/bbreport/wiki/PythonBuildbotReport

Thanks to Florent and Ezio for their great work on bbreport project!

>  - *New failures* : failures which are not associated with an issue in
> the tracker
> 
>  - *Known issues* : failures which are (probably) linked with an existing
> issue (the association [failure] <--> [issue] is based on regexp rules)

There is a configuration file, bbreport.conf, which uses some patterns to match 
an issue:

 - test name (regex)
 - message (regex)
 - builder (regex)

All fields are optional, but it's better to set at least one field :-)

Extract of the config:
---------------
8265: test_float::ARMv4 Debian (2.6|3.1)
8423: test_pep277::x86 Tiger (2.7|3.x)
8428: test_multiprocessing::(x86 FreeBSD 7.2 3.x|x86 Windows7 3.1|.* 2.7)
8429: test_subprocess:hung:
8431: :hung:(ARM|.* debian parallel)
---------------

-- 
Victor Stinner
http://www.haypocalc.com/

From daniel at stutzbachenterprises.com  Sat Aug 21 04:23:05 2010
From: daniel at stutzbachenterprises.com (Daniel Stutzbach)
Date: Fri, 20 Aug 2010 21:23:05 -0500
Subject: [Python-Dev] Request for commits and/or privileges
Message-ID: <AANLkTin8v4rt=FvaE0y=fbWLUc-LXo+CjFkPzHiT=JJ+@mail.gmail.com>

Several issues that I'm involved with (listed below) are ready for
commit, as far as I can tell.  They have a patch, and either a core
developer has positively reviewed the patch or the patch is a
straightforward implementation of a core developer's suggested
approach.  They are all bug-fixes or optimizations.

May I have commit privileges so that I can commit these patches and
future patches in a similar state?  If the consensus is negative for
any reason, I completely respect that decision and will continue to
contribute patches just as I am now (but in that case, consider this
my humble request for someone to commit these changes :) ).  If
positive, I would start by committing just one (after writing an
appropriate NEWS entry) and soliciting feedback to make sure that I
had done it right.

http://bugs.python.org/issue8781 - 32-bit wchar_t doesn't need to be
unsigned to be usable
http://bugs.python.org/issue9214 - Most Set methods of KeysView and
ItemsView do not work right
http://bugs.python.org/issue8750 - Many of MutableSet's methods assume
that the other parameter is not self
http://bugs.python.org/issue5553 - Py_LOCAL_INLINE(type) doesn't
actually inline except using MSC
http://bugs.python.org/issue2521 - ABC caches should use weak refs
http://bugs.python.org/issue808164 - socket.close() doesn't play well
with __del__

Many more in the pipeline :-)

--
Daniel Stutzbach, Ph.D.
President, Stutzbach Enterprises, LLC

From guido at python.org  Sat Aug 21 05:53:46 2010
From: guido at python.org (Guido van Rossum)
Date: Fri, 20 Aug 2010 20:53:46 -0700
Subject: [Python-Dev] Request for commits and/or privileges
In-Reply-To: <AANLkTin8v4rt=FvaE0y=fbWLUc-LXo+CjFkPzHiT=JJ+@mail.gmail.com>
References: <AANLkTin8v4rt=FvaE0y=fbWLUc-LXo+CjFkPzHiT=JJ+@mail.gmail.com>
Message-ID: <AANLkTikN1CmHQ+4qvThe9bPs7sjiiPbvphcyS5JNo=Ug@mail.gmail.com>

+1

On Fri, Aug 20, 2010 at 7:23 PM, Daniel Stutzbach
<daniel at stutzbachenterprises.com> wrote:
> Several issues that I'm involved with (listed below) are ready for
> commit, as far as I can tell. ?They have a patch, and either a core
> developer has positively reviewed the patch or the patch is a
> straightforward implementation of a core developer's suggested
> approach. ?They are all bug-fixes or optimizations.
>
> May I have commit privileges so that I can commit these patches and
> future patches in a similar state? ?If the consensus is negative for
> any reason, I completely respect that decision and will continue to
> contribute patches just as I am now (but in that case, consider this
> my humble request for someone to commit these changes :) ). ?If
> positive, I would start by committing just one (after writing an
> appropriate NEWS entry) and soliciting feedback to make sure that I
> had done it right.
>
> http://bugs.python.org/issue8781 - 32-bit wchar_t doesn't need to be
> unsigned to be usable
> http://bugs.python.org/issue9214 - Most Set methods of KeysView and
> ItemsView do not work right
> http://bugs.python.org/issue8750 - Many of MutableSet's methods assume
> that the other parameter is not self
> http://bugs.python.org/issue5553 - Py_LOCAL_INLINE(type) doesn't
> actually inline except using MSC
> http://bugs.python.org/issue2521 - ABC caches should use weak refs
> http://bugs.python.org/issue808164 - socket.close() doesn't play well
> with __del__
>
> Many more in the pipeline :-)
>
> --
> Daniel Stutzbach, Ph.D.
> President, Stutzbach Enterprises, LLC
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org
>



-- 
--Guido van Rossum (python.org/~guido)

From martin at v.loewis.de  Sat Aug 21 10:47:12 2010
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 21 Aug 2010 10:47:12 +0200
Subject: [Python-Dev] Request for commits and/or privileges
In-Reply-To: <AANLkTin8v4rt=FvaE0y=fbWLUc-LXo+CjFkPzHiT=JJ+@mail.gmail.com>
References: <AANLkTin8v4rt=FvaE0y=fbWLUc-LXo+CjFkPzHiT=JJ+@mail.gmail.com>
Message-ID: <4C6F9290.1020105@v.loewis.de>

> May I have commit privileges so that I can commit these patches and
> future patches in a similar state?

Please send me your SSH key.

Regards,
Martin

From solipsis at pitrou.net  Sat Aug 21 12:01:29 2010
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sat, 21 Aug 2010 12:01:29 +0200
Subject: [Python-Dev] r84229 - in python/branches/py3k:
 Doc/library/codecs.rst Lib/encodings/aliases.py Misc/NEWS
References: <20100821025444.EEA5BEE9BC@mail.python.org>
Message-ID: <20100821120129.3963a25d@pitrou.net>

On Sat, 21 Aug 2010 04:54:44 +0200 (CEST)
benjamin.peterson <python-checkins at python.org> wrote:
> Log:
> alias macintosh to mac_roman #843590
> 
[...]
>  
>      # mac_roman codec
> +    'macintosh'          : 'macintosh',
>      'macroman'           : 'mac_roman',

I'm not sure what is achieved by aliasing 'macintosh' to itself?

Regards

Antoine.



From g.brandl at gmx.net  Sat Aug 21 12:52:25 2010
From: g.brandl at gmx.net (Georg Brandl)
Date: Sat, 21 Aug 2010 12:52:25 +0200
Subject: [Python-Dev] r84229 - in python/branches/py3k:
 Doc/library/codecs.rst Lib/encodings/aliases.py Misc/NEWS
In-Reply-To: <20100821025444.EEA5BEE9BC@mail.python.org>
References: <20100821025444.EEA5BEE9BC@mail.python.org>
Message-ID: <i4obam$n03$1@dough.gmane.org>

Am 21.08.2010 04:54, schrieb benjamin.peterson:
> Author: benjamin.peterson
> Date: Sat Aug 21 04:54:44 2010
> New Revision: 84229
> 
> Log:
> alias macintosh to mac_roman #843590
> 
> Modified:
>    python/branches/py3k/Doc/library/codecs.rst
>    python/branches/py3k/Lib/encodings/aliases.py
>    python/branches/py3k/Misc/NEWS
> 
> Modified: python/branches/py3k/Doc/library/codecs.rst
> ==============================================================================
> --- python/branches/py3k/Doc/library/codecs.rst	(original)
> +++ python/branches/py3k/Doc/library/codecs.rst	Sat Aug 21 04:54:44 2010
> @@ -1090,7 +1090,7 @@
>  +-----------------+--------------------------------+--------------------------------+
>  | mac_latin2      | maclatin2, maccentraleurope    | Central and Eastern Europe     |
>  +-----------------+--------------------------------+--------------------------------+
> -| mac_roman       | macroman                       | Western Europe                 |
> +| mac_roman       | macroman, macintosh            | Western Europe                 |
>  +-----------------+--------------------------------+--------------------------------+
>  | mac_turkish     | macturkish                     | Turkish                        |
>  +-----------------+--------------------------------+--------------------------------+

versionadded is missing.

> Modified: python/branches/py3k/Lib/encodings/aliases.py
> ==============================================================================
> --- python/branches/py3k/Lib/encodings/aliases.py	(original)
> +++ python/branches/py3k/Lib/encodings/aliases.py	Sat Aug 21 04:54:44 2010
> @@ -435,6 +435,7 @@
>      'maclatin2'          : 'mac_latin2',
>  
>      # mac_roman codec
> +    'macintosh'          : 'macintosh',
>      'macroman'           : 'mac_roman',

Should that be 'macintosh': 'mac_roman' instead?

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.


From mal at egenix.com  Sat Aug 21 13:00:14 2010
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat, 21 Aug 2010 13:00:14 +0200
Subject: [Python-Dev] r84229 - in
 python/branches/py3k:	Doc/library/codecs.rst Lib/encodings/aliases.py
 Misc/NEWS
In-Reply-To: <i4obam$n03$1@dough.gmane.org>
References: <20100821025444.EEA5BEE9BC@mail.python.org>
	<i4obam$n03$1@dough.gmane.org>
Message-ID: <4C6FB1BE.30208@egenix.com>

Georg Brandl wrote:
> Am 21.08.2010 04:54, schrieb benjamin.peterson:
>> Author: benjamin.peterson
>> Date: Sat Aug 21 04:54:44 2010
>> New Revision: 84229
>>
>> Log:
>> alias macintosh to mac_roman #843590
>>
>> Modified:
>>    python/branches/py3k/Doc/library/codecs.rst
>>    python/branches/py3k/Lib/encodings/aliases.py
>>    python/branches/py3k/Misc/NEWS
>>
>> Modified: python/branches/py3k/Doc/library/codecs.rst
>> ==============================================================================
>> --- python/branches/py3k/Doc/library/codecs.rst	(original)
>> +++ python/branches/py3k/Doc/library/codecs.rst	Sat Aug 21 04:54:44 2010
>> @@ -1090,7 +1090,7 @@
>>  +-----------------+--------------------------------+--------------------------------+
>>  | mac_latin2      | maclatin2, maccentraleurope    | Central and Eastern Europe     |
>>  +-----------------+--------------------------------+--------------------------------+
>> -| mac_roman       | macroman                       | Western Europe                 |
>> +| mac_roman       | macroman, macintosh            | Western Europe                 |
>>  +-----------------+--------------------------------+--------------------------------+
>>  | mac_turkish     | macturkish                     | Turkish                        |
>>  +-----------------+--------------------------------+--------------------------------+
> 
> versionadded is missing.

Where should that go ? Under the table somewhere ?

>> Modified: python/branches/py3k/Lib/encodings/aliases.py
>> ==============================================================================
>> --- python/branches/py3k/Lib/encodings/aliases.py	(original)
>> +++ python/branches/py3k/Lib/encodings/aliases.py	Sat Aug 21 04:54:44 2010
>> @@ -435,6 +435,7 @@
>>      'maclatin2'          : 'mac_latin2',
>>  
>>      # mac_roman codec
>> +    'macintosh'          : 'macintosh',
>>      'macroman'           : 'mac_roman',
> 
> Should that be 'macintosh': 'mac_roman' instead?

I've fixed that.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Aug 21 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/
________________________________________________________________________

::: 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/

From g.brandl at gmx.net  Sat Aug 21 13:42:51 2010
From: g.brandl at gmx.net (Georg Brandl)
Date: Sat, 21 Aug 2010 13:42:51 +0200
Subject: [Python-Dev] r84229 - in python/branches/py3k:
 Doc/library/codecs.rst Lib/encodings/aliases.py Misc/NEWS
In-Reply-To: <4C6FB1BE.30208@egenix.com>
References: <20100821025444.EEA5BEE9BC@mail.python.org>	<i4obam$n03$1@dough.gmane.org>
	<4C6FB1BE.30208@egenix.com>
Message-ID: <i4oe98$e1$1@dough.gmane.org>

Am 21.08.2010 13:00, schrieb M.-A. Lemburg:
> Georg Brandl wrote:
>> Am 21.08.2010 04:54, schrieb benjamin.peterson:
>>> Author: benjamin.peterson
>>> Date: Sat Aug 21 04:54:44 2010
>>> New Revision: 84229
>>>
>>> Log:
>>> alias macintosh to mac_roman #843590
>>>
>>> Modified:
>>>    python/branches/py3k/Doc/library/codecs.rst
>>>    python/branches/py3k/Lib/encodings/aliases.py
>>>    python/branches/py3k/Misc/NEWS
>>>
>>> Modified: python/branches/py3k/Doc/library/codecs.rst
>>> ==============================================================================
>>> --- python/branches/py3k/Doc/library/codecs.rst	(original)
>>> +++ python/branches/py3k/Doc/library/codecs.rst	Sat Aug 21 04:54:44 2010
>>> @@ -1090,7 +1090,7 @@
>>>  +-----------------+--------------------------------+--------------------------------+
>>>  | mac_latin2      | maclatin2, maccentraleurope    | Central and Eastern Europe     |
>>>  +-----------------+--------------------------------+--------------------------------+
>>> -| mac_roman       | macroman                       | Western Europe                 |
>>> +| mac_roman       | macroman, macintosh            | Western Europe                 |
>>>  +-----------------+--------------------------------+--------------------------------+
>>>  | mac_turkish     | macturkish                     | Turkish                        |
>>>  +-----------------+--------------------------------+--------------------------------+
>> 
>> versionadded is missing.
> 
> Where should that go ? Under the table somewhere ?

I'd say yes.

>>> Modified: python/branches/py3k/Lib/encodings/aliases.py
>>> ==============================================================================
>>> --- python/branches/py3k/Lib/encodings/aliases.py	(original)
>>> +++ python/branches/py3k/Lib/encodings/aliases.py	Sat Aug 21 04:54:44 2010
>>> @@ -435,6 +435,7 @@
>>>      'maclatin2'          : 'mac_latin2',
>>>  
>>>      # mac_roman codec
>>> +    'macintosh'          : 'macintosh',
>>>      'macroman'           : 'mac_roman',
>> 
>> Should that be 'macintosh': 'mac_roman' instead?
> 
> I've fixed that.

Thanks.

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.


From raymond.hettinger at gmail.com  Sat Aug 21 19:41:15 2010
From: raymond.hettinger at gmail.com (Raymond Hettinger)
Date: Sat, 21 Aug 2010 10:41:15 -0700
Subject: [Python-Dev] Request for commits and/or privileges
In-Reply-To: <AANLkTikN1CmHQ+4qvThe9bPs7sjiiPbvphcyS5JNo=Ug@mail.gmail.com>
References: <AANLkTin8v4rt=FvaE0y=fbWLUc-LXo+CjFkPzHiT=JJ+@mail.gmail.com>
	<AANLkTikN1CmHQ+4qvThe9bPs7sjiiPbvphcyS5JNo=Ug@mail.gmail.com>
Message-ID: <3AB049B7-4A5B-4BC1-910D-496F8ECFB260@gmail.com>

+1 from me too.

When you start, olease do leave me as the primary maintainer 
for issues relating to sets and set ABCs.


Raymond


On Aug 20, 2010, at 8:53 PM, Guido van Rossum wrote:

> +1
> 
> On Fri, Aug 20, 2010 at 7:23 PM, Daniel Stutzbach
> <daniel at stutzbachenterprises.com> wrote:
>> Several issues that I'm involved with (listed below) are ready for
>> commit, as far as I can tell.  They have a patch, and either a core
>> developer has positively reviewed the patch or the patch is a
>> straightforward implementation of a core developer's suggested
>> approach.  They are all bug-fixes or optimizations.
>> 
>> May I have commit privileges so that I can commit these patches and
>> future patches in a similar state?  If the consensus is negative for
>> any reason, I completely respect that decision and will continue to
>> contribute patches just as I am now (but in that case, consider this
>> my humble request for someone to commit these changes :) ).  If
>> positive, I would start by committing just one (after writing an
>> appropriate NEWS entry) and soliciting feedback to make sure that I
>> had done it right.
>> 
>> http://bugs.python.org/issue8781 - 32-bit wchar_t doesn't need to be
>> unsigned to be usable
>> http://bugs.python.org/issue9214 - Most Set methods of KeysView and
>> ItemsView do not work right
>> http://bugs.python.org/issue8750 - Many of MutableSet's methods assume
>> that the other parameter is not self
>> http://bugs.python.org/issue5553 - Py_LOCAL_INLINE(type) doesn't
>> actually inline except using MSC
>> http://bugs.python.org/issue2521 - ABC caches should use weak refs
>> http://bugs.python.org/issue808164 - socket.close() doesn't play well
>> with __del__
>> 
>> Many more in the pipeline :-)
>> 
>> --
>> Daniel Stutzbach, Ph.D.
>> President, Stutzbach Enterprises, LLC
>> _______________________________________________
>> Python-Dev mailing list
>> Python-Dev at python.org
>> http://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org
>> 
> 
> 
> 
> -- 
> --Guido van Rossum (python.org/~guido)
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/raymond.hettinger%40gmail.com


From daniel at stutzbachenterprises.com  Sun Aug 22 08:31:31 2010
From: daniel at stutzbachenterprises.com (Daniel Stutzbach)
Date: Sun, 22 Aug 2010 01:31:31 -0500
Subject: [Python-Dev] Request for commits and/or privileges
In-Reply-To: <3AB049B7-4A5B-4BC1-910D-496F8ECFB260@gmail.com>
References: <AANLkTin8v4rt=FvaE0y=fbWLUc-LXo+CjFkPzHiT=JJ+@mail.gmail.com>
	<AANLkTikN1CmHQ+4qvThe9bPs7sjiiPbvphcyS5JNo=Ug@mail.gmail.com>
	<3AB049B7-4A5B-4BC1-910D-496F8ECFB260@gmail.com>
Message-ID: <AANLkTi=R6=JCAHt-Ux0vYo87bo=A=q3SwiYmSw+_m7kg@mail.gmail.com>

On Sat, Aug 21, 2010 at 12:41 PM, Raymond Hettinger
<raymond.hettinger at gmail.com> wrote:
> +1 from me too.
>
> When you start, olease do leave me as the primary maintainer
> for issues relating to sets and set ABCs.

I see myself as the primary maintainer of nothing.  :-)  I would not
commit anything related to sets or set ABCs unless you have signed off
on it in some way.  Perhaps in time there will be some piece of Python
that I've modified so heavily that I become ipso facto the primary
maintainer, but I'm in no hurry.

--
Daniel Stutzbach, Ph.D.
President, Stutzbach Enterprises, LLC

From daniel at stutzbachenterprises.com  Sun Aug 22 08:45:08 2010
From: daniel at stutzbachenterprises.com (Daniel Stutzbach)
Date: Sun, 22 Aug 2010 01:45:08 -0500
Subject: [Python-Dev] Request for commits and/or privileges
In-Reply-To: <4C6F9290.1020105@v.loewis.de>
References: <AANLkTin8v4rt=FvaE0y=fbWLUc-LXo+CjFkPzHiT=JJ+@mail.gmail.com>
	<4C6F9290.1020105@v.loewis.de>
Message-ID: <AANLkTim28oRuV900fza9dE1AHv9iuS+=bvPTYJMsdPLu@mail.gmail.com>

On Sat, Aug 21, 2010 at 3:47 AM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> Please send me your SSH key.

Done.

I have also subscribed to python-committers and python-checkins.  I
will add my interests to Misc/maintainers.rst.  Are there any other
initial start-up tasks I should perform?

--
Daniel Stutzbach, Ph.D.
President, Stutzbach Enterprises, LLC

From brett at python.org  Sun Aug 22 20:53:17 2010
From: brett at python.org (Brett Cannon)
Date: Sun, 22 Aug 2010 11:53:17 -0700
Subject: [Python-Dev] Request for commits and/or privileges
In-Reply-To: <AANLkTim28oRuV900fza9dE1AHv9iuS+=bvPTYJMsdPLu@mail.gmail.com>
References: <AANLkTin8v4rt=FvaE0y=fbWLUc-LXo+CjFkPzHiT=JJ+@mail.gmail.com>
	<4C6F9290.1020105@v.loewis.de>
	<AANLkTim28oRuV900fza9dE1AHv9iuS+=bvPTYJMsdPLu@mail.gmail.com>
Message-ID: <AANLkTikA2qD25k1TiyHuhhu5BOcju2H1GsZB3NeBoWAV@mail.gmail.com>

On Sat, Aug 21, 2010 at 23:45, Daniel Stutzbach
<daniel at stutzbachenterprises.com> wrote:
> On Sat, Aug 21, 2010 at 3:47 AM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>> Please send me your SSH key.
>
> Done.
>
> I have also subscribed to python-committers and python-checkins. ?I
> will add my interests to Misc/maintainers.rst. ?Are there any other
> initial start-up tasks I should perform?

Those are the biggies since you already know how to create patches and such.

-Brett


>
> --
> Daniel Stutzbach, Ph.D.
> President, Stutzbach Enterprises, LLC
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/brett%40python.org
>

From steve at holdenweb.com  Mon Aug 23 04:01:49 2010
From: steve at holdenweb.com (Steve Holden)
Date: Sun, 22 Aug 2010 22:01:49 -0400
Subject: [Python-Dev] Shared Folders Under Vista
Message-ID: <i4sksc$r0v$1@dough.gmane.org>

Folders that I create with Cygwin using mkdir appear to be shared - sort
of. They are denoted with the shared folder icon, and when I use Windows
Explorer to delete them I get the warning about the folder being shared.

When I look at the folder's properties, however, Explorer insists the
the folder is not shared.

Can someone explain how to avoid the sharing in the first place?

regards
 Steve
-- 
Steve Holden           +1 571 484 6266   +1 800 494 3119
DjangoCon US September 7-9, 2010    http://djangocon.us/
See Python Video!       http://python.mirocommunity.org/
Holden Web LLC                 http://www.holdenweb.com/


From daniel at stutzbachenterprises.com  Mon Aug 23 04:10:35 2010
From: daniel at stutzbachenterprises.com (Daniel Stutzbach)
Date: Sun, 22 Aug 2010 21:10:35 -0500
Subject: [Python-Dev] Shared Folders Under Vista
In-Reply-To: <i4sksc$r0v$1@dough.gmane.org>
References: <i4sksc$r0v$1@dough.gmane.org>
Message-ID: <AANLkTik7+6XzeXwmZsT1QBGpRECj5o+_z--WEjN6=JuC@mail.gmail.com>

On Sun, Aug 22, 2010 at 9:01 PM, Steve Holden <steve at holdenweb.com> wrote:
> Folders that I create with Cygwin using mkdir appear to be shared - sort
> of. They are denoted with the shared folder icon, and when I use Windows
> Explorer to delete them I get the warning about the folder being shared.

When you say "mkdir", what exactly do you mean?
/usr/bin/mkdir?  If so, what does this question have to do with Python?
Python's os.mkdir?  If so, which version of Python are you using?

What version of Windows are you running?  For what it's worth, I just tried
both of the above on my XP/Cygwin system and did not see the shared folder
icon in Explorer.
--
Daniel Stutzbach, Ph.D.
President, Stutzbach Enterprises, LLC <http://stutzbachenterprises.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100822/072849c4/attachment.html>

From steve at holdenweb.com  Mon Aug 23 04:17:54 2010
From: steve at holdenweb.com (Steve Holden)
Date: Sun, 22 Aug 2010 22:17:54 -0400
Subject: [Python-Dev] Shared Folders Under Vista
In-Reply-To: <AANLkTik7+6XzeXwmZsT1QBGpRECj5o+_z--WEjN6=JuC@mail.gmail.com>
References: <i4sksc$r0v$1@dough.gmane.org>
	<AANLkTik7+6XzeXwmZsT1QBGpRECj5o+_z--WEjN6=JuC@mail.gmail.com>
Message-ID: <i4slqh$t6k$1@dough.gmane.org>

On 8/22/2010 10:10 PM, Daniel Stutzbach wrote:
> On Sun, Aug 22, 2010 at 9:01 PM, Steve Holden <steve at holdenweb.com
> <mailto:steve at holdenweb.com>> wrote:
>> Folders that I create with Cygwin using mkdir appear to be shared - sort
>> of. They are denoted with the shared folder icon, and when I use Windows
>> Explorer to delete them I get the warning about the folder being shared.
> 
> When you say "mkdir", what exactly do you mean?
> /usr/bin/mkdir?  If so, what does this question have to do with Python?
> Python's os.mkdir?  If so, which version of Python are you using?
> 
> What version of Windows are you running?  For what it's worth, I just
> tried both of the above on my XP/Cygwin system and did not see the
> shared folder icon in Explorer.

Sorry - intended to post this on the Cygwin mailing list.

regards
 Steve
-- 
Steve Holden           +1 571 484 6266   +1 800 494 3119
DjangoCon US September 7-9, 2010    http://djangocon.us/
See Python Video!       http://python.mirocommunity.org/
Holden Web LLC                 http://www.holdenweb.com/


From breamoreboy at yahoo.co.uk  Mon Aug 23 16:13:34 2010
From: breamoreboy at yahoo.co.uk (Mark Lawrence)
Date: Mon, 23 Aug 2010 15:13:34 +0100
Subject: [Python-Dev] bugs.python.org
Message-ID: <i4tvme$hf8$1@dough.gmane.org>

Suffering from dead parrot syndrome?  Kiss of life please :)

Kindest regards.

Mark Lawrence.


From yselivanov at gmail.com  Mon Aug 23 16:22:22 2010
From: yselivanov at gmail.com (Yury Selivanov)
Date: Mon, 23 Aug 2010 10:22:22 -0400
Subject: [Python-Dev] 'hasattr' is broken by design
Message-ID: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>

Hello,

I know the issue has been discussed several times already, however I couldn't find any reasonable explanation of its strange behaviour.  The main problem with 'hasattr' function is that is swallows all exceptions derived from Exception class.  It's a good thing that it doesn't do that with BaseException as it was fixed not a long time ago, but it's definitely not enough.

First of all, this behaviour of 'hasattr' contradicts with the very core principle of python: "Errors should never pass silently."  And since 'hasattr' function is in builtins module and is a widely used function it impacts the whole language.

Secondly, take a look at the following:

    >>> class Test:
    ...     @property
    ...     def attr(self):
    ...         self['foo']
    ... 
    >>> hasattr(Test(), 'attr')
    False

There can be any exception instead of KeyError in the above snippet of code, but this small example shows how 'hasattr': misleadingly breaks the code logic (1) and masks bug (2).  And that's the simplest possible example, there are much more in real life.

While (1) is maybe acceptable for someone, there is no excuse for the (2).  Moreover, current 'hasattr' behaviour tremendously complicates use of '__getattribute__' magic.  And forget about importlib magic with LazyImports, one 'hasattr' ruins everything by catching ImportError.


To conclude:

1) I propose to change 'hasattr' behaviour in Python 3, making it to swallow only AttributeError exceptions (exactly like 'getattr').  Probably, Python 3.2 release is our last chance.

2) If you afraid that this new behaviour will break too much python 2 code converted with 2to3, we can introduce another 'hasattr' function defined in 2to3 module itself, and make it imported automatically in all files passed through 2to3 transformation pipeline.  This new function will mimic 'hasattr' behaviour from python 2 and converted code should work as expected.


-
Yury Selivanov,
Sprymix Inc.
+1-416-509-2807


From benjamin at python.org  Mon Aug 23 16:46:15 2010
From: benjamin at python.org (Benjamin Peterson)
Date: Mon, 23 Aug 2010 09:46:15 -0500
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
Message-ID: <AANLkTimo2u2xGm3DjT7KU4uHM+_0JuwdjsQtCSYow15z@mail.gmail.com>

2010/8/23 Yury Selivanov <yselivanov at gmail.com>:
> 1) I propose to change 'hasattr' behaviour in Python 3, making it to swallow only AttributeError exceptions (exactly like 'getattr'). ?Probably, Python 3.2 release is our last chance.

I would be in support of that.

>
> 2) If you afraid that this new behaviour will break too much python 2 code converted with 2to3, we can introduce another 'hasattr' function defined in 2to3 module itself, and make it imported automatically in all files passed through 2to3 transformation pipeline. ?This new function will mimic 'hasattr' behaviour from python 2 and converted code should work as expected.

But not this. Compatibility functions don't belong in 2to3.

-- 
Regards,
Benjamin

From yselivanov at gmail.com  Mon Aug 23 16:52:22 2010
From: yselivanov at gmail.com (Yury Selivanov)
Date: Mon, 23 Aug 2010 10:52:22 -0400
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <AANLkTimo2u2xGm3DjT7KU4uHM+_0JuwdjsQtCSYow15z@mail.gmail.com>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
	<AANLkTimo2u2xGm3DjT7KU4uHM+_0JuwdjsQtCSYow15z@mail.gmail.com>
Message-ID: <108D569A-668B-4A0A-AF75-9D0D1BBE1456@gmail.com>

On 2010-08-23, at 10:46 AM, Benjamin Peterson wrote:

> 2010/8/23 Yury Selivanov <yselivanov at gmail.com>:
>> 1) I propose to change 'hasattr' behaviour in Python 3, making it to swallow only AttributeError exceptions (exactly like 'getattr').  Probably, Python 3.2 release is our last chance.
> 
> I would be in support of that.
> 
>> 
>> 2) If you afraid that this new behaviour will break too much python 2 code converted with 2to3, we can introduce another 'hasattr' function defined in 2to3 module itself, and make it imported automatically in all files passed through 2to3 transformation pipeline.  This new function will mimic 'hasattr' behaviour from python 2 and converted code should work as expected.
> 
> But not this. Compatibility functions don't belong in 2to3.

There are many possible solutions for the Python 2 porting issue, this one was just one of them.  I was trying to make a point, that it's possible to somehow make porting process easier, and meanwhile fix Python 3.

-
Yury Selivanov
Sprymix Inc.


From guido at python.org  Mon Aug 23 16:56:50 2010
From: guido at python.org (Guido van Rossum)
Date: Mon, 23 Aug 2010 07:56:50 -0700
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <AANLkTimo2u2xGm3DjT7KU4uHM+_0JuwdjsQtCSYow15z@mail.gmail.com>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
	<AANLkTimo2u2xGm3DjT7KU4uHM+_0JuwdjsQtCSYow15z@mail.gmail.com>
Message-ID: <AANLkTi=9E3_Bo1X9_gPxaK5dUrA=whmZbBdHY+Qknt_S@mail.gmail.com>

On Mon, Aug 23, 2010 at 7:46 AM, Benjamin Peterson <benjamin at python.org> wrote:
> 2010/8/23 Yury Selivanov <yselivanov at gmail.com>:
>> 1) I propose to change 'hasattr' behaviour in Python 3, making it to swallow only AttributeError exceptions (exactly like 'getattr'). ?Probably, Python 3.2 release is our last chance.
>
> I would be in support of that.

I am cautiously in favor. The existing behavior is definitely a
mistake and a trap. But it has been depended on for almost 20 years
now.

I recommend that you create a patch, apply it, run the *entire* stdlib
test suite and see how much breaks. That will give you an idea of the
damage to expect for 3rd party code.

>> 2) If you afraid that this new behaviour will break too much python 2 code converted with 2to3, we can introduce another 'hasattr' function defined in 2to3 module itself, and make it imported automatically in all files passed through 2to3 transformation pipeline. ?This new function will mimic 'hasattr' behaviour from python 2 and converted code should work as expected.
>
> But not this. Compatibility functions don't belong in 2to3.

Indeed.

-- 
--Guido van Rossum (python.org/~guido)

From rdmurray at bitdance.com  Mon Aug 23 17:05:58 2010
From: rdmurray at bitdance.com (R. David Murray)
Date: Mon, 23 Aug 2010 11:05:58 -0400
Subject: [Python-Dev] bugs.python.org
In-Reply-To: <i4tvme$hf8$1@dough.gmane.org>
References: <i4tvme$hf8$1@dough.gmane.org>
Message-ID: <20100823150558.487E621D9CA@kimball.webabinitio.net>

On Mon, 23 Aug 2010 15:13:34 +0100, Mark Lawrence <breamoreboy at yahoo.co.uk> wrote:
> Suffering from dead parrot syndrome?  Kiss of life please :)

The hosting company has been notified.

--David

From benjamin at python.org  Mon Aug 23 17:24:48 2010
From: benjamin at python.org (Benjamin Peterson)
Date: Mon, 23 Aug 2010 10:24:48 -0500
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <AANLkTi=9E3_Bo1X9_gPxaK5dUrA=whmZbBdHY+Qknt_S@mail.gmail.com>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
	<AANLkTimo2u2xGm3DjT7KU4uHM+_0JuwdjsQtCSYow15z@mail.gmail.com>
	<AANLkTi=9E3_Bo1X9_gPxaK5dUrA=whmZbBdHY+Qknt_S@mail.gmail.com>
Message-ID: <AANLkTin7ccAEOOuWqiHfLspcTtVNSaJ8xy-tcn=jDvm5@mail.gmail.com>

2010/8/23 Guido van Rossum <guido at python.org>:
> On Mon, Aug 23, 2010 at 7:46 AM, Benjamin Peterson <benjamin at python.org> wrote:
>> 2010/8/23 Yury Selivanov <yselivanov at gmail.com>:
>>> 1) I propose to change 'hasattr' behaviour in Python 3, making it to swallow only AttributeError exceptions (exactly like 'getattr'). ?Probably, Python 3.2 release is our last chance.
>>
>> I would be in support of that.
>
> I am cautiously in favor. The existing behavior is definitely a
> mistake and a trap. But it has been depended on for almost 20 years
> now.
>
> I recommend that you create a patch, apply it, run the *entire* stdlib
> test suite and see how much breaks. That will give you an idea of the
> damage to expect for 3rd party code.

The test suite passes complete without modification for me.



-- 
Regards,
Benjamin

From tseaver at palladion.com  Mon Aug 23 17:58:58 2010
From: tseaver at palladion.com (Tres Seaver)
Date: Mon, 23 Aug 2010 11:58:58 -0400
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <AANLkTi=9E3_Bo1X9_gPxaK5dUrA=whmZbBdHY+Qknt_S@mail.gmail.com>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>	<AANLkTimo2u2xGm3DjT7KU4uHM+_0JuwdjsQtCSYow15z@mail.gmail.com>
	<AANLkTi=9E3_Bo1X9_gPxaK5dUrA=whmZbBdHY+Qknt_S@mail.gmail.com>
Message-ID: <i4u5rv$cgb$1@dough.gmane.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Guido van Rossum wrote:
> On Mon, Aug 23, 2010 at 7:46 AM, Benjamin Peterson <benjamin at python.org> wrote:
>> 2010/8/23 Yury Selivanov <yselivanov at gmail.com>:
>>> 1) I propose to change 'hasattr' behaviour in Python 3, making it to swallow only AttributeError exceptions (exactly like 'getattr').  Probably, Python 3.2 release is our last chance.
>> I would be in support of that.
> 
> I am cautiously in favor. The existing behavior is definitely a
> mistake and a trap. But it has been depended on for almost 20 years
> now.
> 
> I recommend that you create a patch, apply it, run the *entire* stdlib
> test suite and see how much breaks. That will give you an idea of the
> damage to expect for 3rd party code.

Robust third-party code is written to avoid 'hasattr', for precisely
this reason.  Third-party code which relies on 'hasattr' to mask
non-AttributeErrors is broken alreay (it just doesn't show the borkedness).


Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkxymr0ACgkQ+gerLs4ltQ4rQwCgyHJmqt2TefCgX2di5aJ92pVh
26YAnjKrBrK3gMs7ddo2wHtpT+iq2Mbg
=BFxu
-----END PGP SIGNATURE-----


From tjreedy at udel.edu  Mon Aug 23 19:05:51 2010
From: tjreedy at udel.edu (Terry Reedy)
Date: Mon, 23 Aug 2010 13:05:51 -0400
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
Message-ID: <i4u9pf$p1$1@dough.gmane.org>

On 8/23/2010 10:22 AM, Yury Selivanov wrote:

> 1) I propose to change 'hasattr' behaviour in Python 3, making it to
> swallow only AttributeError exceptions (exactly like 'getattr').
> Probably, Python 3.2 release is our last chance.

I gather that this amounts to changing "an exception" to 
"AttributeError" in "(This is implemented by calling getattr(object, 
name) and seeing whether it raises an exception or not.)" in both the 
doc and implementation, so that the implementation actually matches the 
claimed behavior "The result is True if the string is the name of one of 
the object?s attributes, False if not. " (and by reasonable implication, 
an exception if this cannot be determined).

-- 
Terry Jan Reedy



From raymond.hettinger at gmail.com  Mon Aug 23 21:47:00 2010
From: raymond.hettinger at gmail.com (Raymond Hettinger)
Date: Mon, 23 Aug 2010 12:47:00 -0700
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
Message-ID: <2C284C09-3819-4858-A75A-34597DD668B7@gmail.com>


On Aug 23, 2010, at 7:22 AM, Yury Selivanov wrote:

> I know the issue has been discussed several times already, however I couldn't find any reasonable explanation of its strange behaviour.  The main problem with 'hasattr' function is that is swallows all exceptions derived from Exception class.  It's a good thing that it doesn't do that with BaseException as it was fixed not a long time ago, but it's definitely not enough.
> 
> First of all, this behaviour of 'hasattr' contradicts with the very core principle of python: "Errors should never pass silently."  And since 'hasattr' function is in builtins module and is a widely used function it impacts the whole language.
> 
> Secondly, take a look at the following:
> 
>>>> class Test:
>    ...     @property
>    ...     def attr(self):
>    ...         self['foo']
>    ... 
>>>> hasattr(Test(), 'attr')
>    False
> 
> There can be any exception instead of KeyError in the above snippet of code, but this small example shows how 'hasattr': misleadingly breaks the code logic (1) and masks bug (2).  And that's the simplest possible example, there are much more in real life.
> 
> While (1) is maybe acceptable for someone, there is no excuse for the (2).  Moreover, current 'hasattr' behaviour tremendously complicates use of '__getattribute__' magic.  And forget about importlib magic with LazyImports, one 'hasattr' ruins everything by catching ImportError.
> 
> 
> To conclude:
> 
> 1) I propose to change 'hasattr' behaviour in Python 3, making it to swallow only AttributeError exceptions (exactly like 'getattr').  Probably, Python 3.2 release is our last chance.
> 
> 2) If you afraid that this new behaviour will break too much python 2 code converted with 2to3, we can introduce another 'hasattr' function defined in 2to3 module itself, and make it imported automatically in all files passed through 2to3 transformation pipeline.  This new function will mimic 'hasattr' behaviour from python 2 and converted code should work as expected.


Thanks for the nice analysis and good example.

I disagree with the solution though.  If we want to see the exceptions associated 
with actually getting an attribute, then using getattr() instead is a perfectly 
reasonable solution that people can already use without a language change.

But hasattr() has a far different set of use cases, so we should explore
an alternate solution to the problem.  The usual reason that people use
hasattr() instead of getattr() is that they want to check for the presence of
of a method/attribute without actually running it, binding it, or triggering
any other behavior.

As your example shows, property() defeats this intent by actually executing
the code.   A better behavior would not run the code at all.  It would check
the dictionaries along the MRO but not execute any descriptors associated
with a given key.

IMO, this is a much better solution, more in line with known use cases
for hasattr().   If the proposed change when through, it would fail to
address the common use case and cause people to start writing their
own versions of hasattr() that just scan but do not run code.


Raymond



From fuzzyman at voidspace.org.uk  Mon Aug 23 21:56:27 2010
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Mon, 23 Aug 2010 22:56:27 +0300
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <2C284C09-3819-4858-A75A-34597DD668B7@gmail.com>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
	<2C284C09-3819-4858-A75A-34597DD668B7@gmail.com>
Message-ID: <4C72D26B.3060705@voidspace.org.uk>

  On 23/08/2010 22:47, Raymond Hettinger wrote:
> On Aug 23, 2010, at 7:22 AM, Yury Selivanov wrote:
>
>> I know the issue has been discussed several times already, however I couldn't find any reasonable explanation of its strange behaviour.  The main problem with 'hasattr' function is that is swallows all exceptions derived from Exception class.  It's a good thing that it doesn't do that with BaseException as it was fixed not a long time ago, but it's definitely not enough.
>>
>> First of all, this behaviour of 'hasattr' contradicts with the very core principle of python: "Errors should never pass silently."  And since 'hasattr' function is in builtins module and is a widely used function it impacts the whole language.
>>
>> Secondly, take a look at the following:
>>
>>>>> class Test:
>>     ...     @property
>>     ...     def attr(self):
>>     ...         self['foo']
>>     ...
>>>>> hasattr(Test(), 'attr')
>>     False
>>
>> There can be any exception instead of KeyError in the above snippet of code, but this small example shows how 'hasattr': misleadingly breaks the code logic (1) and masks bug (2).  And that's the simplest possible example, there are much more in real life.
>>
>> While (1) is maybe acceptable for someone, there is no excuse for the (2).  Moreover, current 'hasattr' behaviour tremendously complicates use of '__getattribute__' magic.  And forget about importlib magic with LazyImports, one 'hasattr' ruins everything by catching ImportError.
>>
>>
>> To conclude:
>>
>> 1) I propose to change 'hasattr' behaviour in Python 3, making it to swallow only AttributeError exceptions (exactly like 'getattr').  Probably, Python 3.2 release is our last chance.
>>
>> 2) If you afraid that this new behaviour will break too much python 2 code converted with 2to3, we can introduce another 'hasattr' function defined in 2to3 module itself, and make it imported automatically in all files passed through 2to3 transformation pipeline.  This new function will mimic 'hasattr' behaviour from python 2 and converted code should work as expected.
>
> Thanks for the nice analysis and good example.
>
> I disagree with the solution though.  If we want to see the exceptions associated
> with actually getting an attribute, then using getattr() instead is a perfectly
> reasonable solution that people can already use without a language change.
>
> But hasattr() has a far different set of use cases, so we should explore
> an alternate solution to the problem.  The usual reason that people use
> hasattr() instead of getattr() is that they want to check for the presence of
> of a method/attribute without actually running it, binding it, or triggering
> any other behavior.
>
> As your example shows, property() defeats this intent by actually executing
> the code.   A better behavior would not run the code at all.  It would check
> the dictionaries along the MRO but not execute any descriptors associated
> with a given key.
>
> IMO, this is a much better solution, more in line with known use cases
> for hasattr().   If the proposed change when through, it would fail to
> address the common use case and cause people to start writing their
> own versions of hasattr() that just scan but do not run code.
>

It would be backwards incompatible with usage of hasattr for dynamically 
created 'members' using __getattr__ though. For what it's worth I 
*agree* with you [1], but for better or worse hasattr / getattr trigger 
code execution and hasattr can return True for dynamically created 
members. Something to be revisited for Python 4 perhaps.

Michael Foord


[1] A while ago I wrote a couple of blog entries on fetching docstrings 
from members without triggering code execution. It is surprisingly 
convoluted and even my final code had corner cases it didn't handle:
http://www.voidspace.org.uk/python/weblog/arch_d7_2009_05_16.shtml#e1090
http://www.voidspace.org.uk/python/weblog/arch_d7_2009_06_20.shtml#e1103


> Raymond
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at 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/


From benjamin at python.org  Mon Aug 23 21:59:13 2010
From: benjamin at python.org (Benjamin Peterson)
Date: Mon, 23 Aug 2010 14:59:13 -0500
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <2C284C09-3819-4858-A75A-34597DD668B7@gmail.com>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
	<2C284C09-3819-4858-A75A-34597DD668B7@gmail.com>
Message-ID: <AANLkTimFeoZsRdUfWfhSyievK_819KFRoqDO2H3sc2JN@mail.gmail.com>

2010/8/23 Raymond Hettinger <raymond.hettinger at gmail.com>:
> Thanks for the nice analysis and good example.
>
> I disagree with the solution though. ?If we want to see the exceptions associated
> with actually getting an attribute, then using getattr() instead is a perfectly
> reasonable solution that people can already use without a language change.
>
> But hasattr() has a far different set of use cases, so we should explore
> an alternate solution to the problem. ?The usual reason that people use
> hasattr() instead of getattr() is that they want to check for the presence of
> of a method/attribute without actually running it, binding it, or triggering
> any other behavior.

That would break the assumption that:
if hasattr(obj, attr):
     getattr(obj, attr) # won't raise

and hasattr ~=
try:
    getattr(obj, attr)
except AttributeError:
    return False
else:
    return True

>
> As your example shows, property() defeats this intent by actually executing
> the code. ? A better behavior would not run the code at all. ?It would check
> the dictionaries along the MRO but not execute any descriptors associated
> with a given key.

That doesn't sound to useful to me. A descriptor could be found with
__get__, but that __get__ could just as well raise AttributeError.

>
> IMO, this is a much better solution, more in line with known use cases
> for hasattr(). ? If the proposed change when through, it would fail to
> address the common use case and cause people to start writing their
> own versions of hasattr() that just scan but do not run code.

Can you provide an example? I've never seen code which explicitly
scans MRO and dicts to avoid triggering code. (Besides
collections.Callable; that's a special case.)



-- 
Regards,
Benjamin

From pje at telecommunity.com  Mon Aug 23 22:00:06 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Mon, 23 Aug 2010 16:00:06 -0400
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <2C284C09-3819-4858-A75A-34597DD668B7@gmail.com>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
	<2C284C09-3819-4858-A75A-34597DD668B7@gmail.com>
Message-ID: <20100823200010.4BF813A4108@sparrow.telecommunity.com>

At 12:47 PM 8/23/2010 -0700, Raymond Hettinger wrote:
>As your example shows, property() defeats this intent by actually executing
>the code.   A better behavior would not run the code at all.  It would check
>the dictionaries along the MRO but not execute any descriptors associated
>with a given key.

That just introduces a new class of error when the descriptor can 
raise AttributeError (e.g. __slots__ descriptors).  And of course, it 
ignoress __getattr__ and __getattribute__.


From yselivanov at gmail.com  Mon Aug 23 22:00:29 2010
From: yselivanov at gmail.com (Yury Selivanov)
Date: Mon, 23 Aug 2010 16:00:29 -0400
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <2C284C09-3819-4858-A75A-34597DD668B7@gmail.com>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
	<2C284C09-3819-4858-A75A-34597DD668B7@gmail.com>
Message-ID: <46EC1E2D-DDBD-4FC0-AE35-FE81A305987B@gmail.com>

On 2010-08-23, at 3:47 PM, Raymond Hettinger wrote:

> 
> On Aug 23, 2010, at 7:22 AM, Yury Selivanov wrote:
> 
>> I know the issue has been discussed several times already, however I couldn't find any reasonable explanation of its strange behaviour.  The main problem with 'hasattr' function is that is swallows all exceptions derived from Exception class.  It's a good thing that it doesn't do that with BaseException as it was fixed not a long time ago, but it's definitely not enough.
>> 
>> First of all, this behaviour of 'hasattr' contradicts with the very core principle of python: "Errors should never pass silently."  And since 'hasattr' function is in builtins module and is a widely used function it impacts the whole language.
>> 
>> Secondly, take a look at the following:
>> 
>>>>> class Test:
>>   ...     @property
>>   ...     def attr(self):
>>   ...         self['foo']
>>   ... 
>>>>> hasattr(Test(), 'attr')
>>   False
>> 
>> There can be any exception instead of KeyError in the above snippet of code, but this small example shows how 'hasattr': misleadingly breaks the code logic (1) and masks bug (2).  And that's the simplest possible example, there are much more in real life.
>> 
>> While (1) is maybe acceptable for someone, there is no excuse for the (2).  Moreover, current 'hasattr' behaviour tremendously complicates use of '__getattribute__' magic.  And forget about importlib magic with LazyImports, one 'hasattr' ruins everything by catching ImportError.
>> 
>> 
>> To conclude:
>> 
>> 1) I propose to change 'hasattr' behaviour in Python 3, making it to swallow only AttributeError exceptions (exactly like 'getattr').  Probably, Python 3.2 release is our last chance.
>> 
>> 2) If you afraid that this new behaviour will break too much python 2 code converted with 2to3, we can introduce another 'hasattr' function defined in 2to3 module itself, and make it imported automatically in all files passed through 2to3 transformation pipeline.  This new function will mimic 'hasattr' behaviour from python 2 and converted code should work as expected.
> 
> 
> Thanks for the nice analysis and good example.
> 
> I disagree with the solution though.  If we want to see the exceptions associated 
> with actually getting an attribute, then using getattr() instead is a perfectly 
> reasonable solution that people can already use without a language change.
> 
> But hasattr() has a far different set of use cases, so we should explore
> an alternate solution to the problem.  The usual reason that people use
> hasattr() instead of getattr() is that they want to check for the presence of
> of a method/attribute without actually running it, binding it, or triggering
> any other behavior.
> 
> As your example shows, property() defeats this intent by actually executing
> the code.   A better behavior would not run the code at all.  It would check
> the dictionaries along the MRO but not execute any descriptors associated
> with a given key.
> 
> IMO, this is a much better solution, more in line with known use cases
> for hasattr().   If the proposed change when through, it would fail to
> address the common use case and cause people to start writing their
> own versions of hasattr() that just scan but do not run code.

This is impossible to implement because of '__getattribute__' and '__getattr__' methods.  There is no way of detecting the presence of an attribute but trying to get it through 'getattr'.  Partial solution like getting information about property presence through __dict__ and call __getattribute__/__getattr__ if they are defined wouldn't work either.

So, your solution would make 'hasattr' even more incompatible.

-
Yury Selivanov

From guido at python.org  Mon Aug 23 22:03:50 2010
From: guido at python.org (Guido van Rossum)
Date: Mon, 23 Aug 2010 13:03:50 -0700
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <2C284C09-3819-4858-A75A-34597DD668B7@gmail.com>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
	<2C284C09-3819-4858-A75A-34597DD668B7@gmail.com>
Message-ID: <AANLkTinz225t6xO-KH04FiaSPqJ6G9x9JhQ5adMi9_yT@mail.gmail.com>

On Mon, Aug 23, 2010 at 12:47 PM, Raymond Hettinger
<raymond.hettinger at gmail.com> wrote:
>
> On Aug 23, 2010, at 7:22 AM, Yury Selivanov wrote:
>
>> I know the issue has been discussed several times already, however I couldn't find any reasonable explanation of its strange behaviour. ?The main problem with 'hasattr' function is that is swallows all exceptions derived from Exception class. ?It's a good thing that it doesn't do that with BaseException as it was fixed not a long time ago, but it's definitely not enough.
>>
>> First of all, this behaviour of 'hasattr' contradicts with the very core principle of python: "Errors should never pass silently." ?And since 'hasattr' function is in builtins module and is a widely used function it impacts the whole language.
>>
>> Secondly, take a look at the following:
>>
>>>>> class Test:
>> ? ?... ? ? @property
>> ? ?... ? ? def attr(self):
>> ? ?... ? ? ? ? self['foo']
>> ? ?...
>>>>> hasattr(Test(), 'attr')
>> ? ?False
>>
>> There can be any exception instead of KeyError in the above snippet of code, but this small example shows how 'hasattr': misleadingly breaks the code logic (1) and masks bug (2). ?And that's the simplest possible example, there are much more in real life.
>>
>> While (1) is maybe acceptable for someone, there is no excuse for the (2). ?Moreover, current 'hasattr' behaviour tremendously complicates use of '__getattribute__' magic. ?And forget about importlib magic with LazyImports, one 'hasattr' ruins everything by catching ImportError.
>>
>>
>> To conclude:
>>
>> 1) I propose to change 'hasattr' behaviour in Python 3, making it to swallow only AttributeError exceptions (exactly like 'getattr'). ?Probably, Python 3.2 release is our last chance.
>>
>> 2) If you afraid that this new behaviour will break too much python 2 code converted with 2to3, we can introduce another 'hasattr' function defined in 2to3 module itself, and make it imported automatically in all files passed through 2to3 transformation pipeline. ?This new function will mimic 'hasattr' behaviour from python 2 and converted code should work as expected.
>
>
> Thanks for the nice analysis and good example.
>
> I disagree with the solution though. ?If we want to see the exceptions associated
> with actually getting an attribute, then using getattr() instead is a perfectly
> reasonable solution that people can already use without a language change.
>
> But hasattr() has a far different set of use cases, so we should explore
> an alternate solution to the problem. ?The usual reason that people use
> hasattr() instead of getattr() is that they want to check for the presence of
> of a method/attribute without actually running it, binding it, or triggering
> any other behavior.
>
> As your example shows, property() defeats this intent by actually executing
> the code. ? A better behavior would not run the code at all. ?It would check
> the dictionaries along the MRO but not execute any descriptors associated
> with a given key.
>
> IMO, this is a much better solution, more in line with known use cases
> for hasattr(). ? If the proposed change when through, it would fail to
> address the common use case and cause people to start writing their
> own versions of hasattr() that just scan but do not run code.

Hm... That sounds like scope creep to me. Properties are supposed to
be cheap and idempotent. Trying to figure out whether an attribute
exists without using __getattr__ is fraught with problems -- as soon
as a class overrides __getattr__ or __getattribute__ you're hosed
anyway.

I can vouch that the reason hasattr() catches too many exceptions is
that when I first added it (around 1990, I think :-) I wasn't very
attuned yet to the problems it could cause.

The main problem I can see with letting exceptions other than
AttributeError bubble through (besides perverted dependencies on the
current semantics) is that there are some situations where it is
pretty arbitrary whether TypeError or AttributeError is raised. I
can't recall the details, and possibly this was more of a problem with
classic classes, but I do think it warrants some research.

-- 
--Guido van Rossum (python.org/~guido)

From fuzzyman at voidspace.org.uk  Mon Aug 23 22:08:50 2010
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Mon, 23 Aug 2010 23:08:50 +0300
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <AANLkTimFeoZsRdUfWfhSyievK_819KFRoqDO2H3sc2JN@mail.gmail.com>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>	<2C284C09-3819-4858-A75A-34597DD668B7@gmail.com>
	<AANLkTimFeoZsRdUfWfhSyievK_819KFRoqDO2H3sc2JN@mail.gmail.com>
Message-ID: <4C72D552.2030306@voidspace.org.uk>

  On 23/08/2010 22:59, Benjamin Peterson wrote:
> [snip...]
>> IMO, this is a much better solution, more in line with known use cases
>> for hasattr().   If the proposed change when through, it would fail to
>> address the common use case and cause people to start writing their
>> own versions of hasattr() that just scan but do not run code.
> Can you provide an example? I've never seen code which explicitly
> scans MRO and dicts to avoid triggering code. (Besides
> collections.Callable; that's a special case.)
>

The example I linked to in my previous email did exactly that - the use 
case was for finding and displaying docstrings on members in an 
interactive object viewer. We needed to be able to examine objects 
without triggering code execution in them.

To me hasattr *looks* like a passive introspection function, and the 
fact that it can trigger arbitrary code execution is unfortunate - 
especially because a full workaround is pretty arcane.

Michael


>


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


From benjamin at python.org  Mon Aug 23 22:13:51 2010
From: benjamin at python.org (Benjamin Peterson)
Date: Mon, 23 Aug 2010 15:13:51 -0500
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <4C72D552.2030306@voidspace.org.uk>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
	<2C284C09-3819-4858-A75A-34597DD668B7@gmail.com>
	<AANLkTimFeoZsRdUfWfhSyievK_819KFRoqDO2H3sc2JN@mail.gmail.com>
	<4C72D552.2030306@voidspace.org.uk>
Message-ID: <AANLkTinzZ40ykb+JHFFJ9W=4ww5AwiLnd=_s5pVgqVaN@mail.gmail.com>

2010/8/23 Michael Foord <fuzzyman at voidspace.org.uk>:
> To me hasattr *looks* like a passive introspection function, and the fact
> that it can trigger arbitrary code execution is unfortunate - especially
> because a full workaround is pretty arcane.

That's the danger of a dynamic language like Python. Even dir() can
now trigger things like that.


-- 
Regards,
Benjamin

From benjamin at python.org  Mon Aug 23 22:17:46 2010
From: benjamin at python.org (Benjamin Peterson)
Date: Mon, 23 Aug 2010 15:17:46 -0500
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <AANLkTinz225t6xO-KH04FiaSPqJ6G9x9JhQ5adMi9_yT@mail.gmail.com>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
	<2C284C09-3819-4858-A75A-34597DD668B7@gmail.com>
	<AANLkTinz225t6xO-KH04FiaSPqJ6G9x9JhQ5adMi9_yT@mail.gmail.com>
Message-ID: <AANLkTi=7M=24eVNsiVTubwUmcrqjyzTz4U3oN5Ko4HbE@mail.gmail.com>

2010/8/23 Guido van Rossum <guido at python.org>:
> The main problem I can see with letting exceptions other than
> AttributeError bubble through (besides perverted dependencies on the
> current semantics) is that there are some situations where it is
> pretty arbitrary whether TypeError or AttributeError is raised. I
> can't recall the details, and possibly this was more of a problem with
> classic classes, but I do think it warrants some research.

I believe this was with regards to actual operations, though, not
fetching the attribute. For example, float(a) would raise an
AttributeError for a classic instance and a TypeError for a new-style
instance. However both would raise AttributeError on a.__float__.



-- 
Regards,
Benjamin

From raymond.hettinger at gmail.com  Mon Aug 23 22:33:02 2010
From: raymond.hettinger at gmail.com (Raymond Hettinger)
Date: Mon, 23 Aug 2010 13:33:02 -0700
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <AANLkTinz225t6xO-KH04FiaSPqJ6G9x9JhQ5adMi9_yT@mail.gmail.com>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
	<2C284C09-3819-4858-A75A-34597DD668B7@gmail.com>
	<AANLkTinz225t6xO-KH04FiaSPqJ6G9x9JhQ5adMi9_yT@mail.gmail.com>
Message-ID: <46A37D14-D024-4CF8-9BED-E87B69734B8C@gmail.com>


On Aug 23, 2010, at 1:03 PM, Guido van Rossum wrote:

>> But hasattr() has a far different set of use cases, so we should explore
>> an alternate solution to the problem.  The usual reason that people use
>> hasattr() instead of getattr() is that they want to check for the presence of
>> of a method/attribute without actually running it, binding it, or triggering
>> any other behavior.
>> 
>> As your example shows, property() defeats this intent by actually executing
>> the code.   A better behavior would not run the code at all.  It would check
>> the dictionaries along the MRO but not execute any descriptors associated
>> with a given key.
>> 
>> IMO, this is a much better solution, more in line with known use cases
>> for hasattr().   If the proposed change when through, it would fail to
>> address the common use case and cause people to start writing their
>> own versions of hasattr() that just scan but do not run code.
> 
> Hm... That sounds like scope creep to me. Properties are supposed to
> be cheap and idempotent. Trying to figure out whether an attribute
> exists without using __getattr__ is fraught with problems -- as soon
> as a class overrides __getattr__ or __getattribute__ you're hosed
> anyway.

I don't have a specific proposal in mind.  My main questions are

* Is there anything that hasattr(obj, key) can or should do that
  can't already be done with getattr(obj, key, None)? 
  If not, do we really need to change anything?

* Why do people typically use hasattr() instead getattr()?  
   Aren't they are really trying to just determine 
   whether a key exists somewhere in the MRO?
   If so, then doing anything more than that is probably a surprise.

I know my own uses of hasattr() do not expect any exceptions at all.
It comes up in duck typing support different handling for different 
types of inputs.  If others are using it the same way, I think it is
unlikely that they have unittests to cover the possibility that
hasattr() would ever start raising exceptions.


> I can vouch that the reason hasattr() catches too many exceptions is
> that when I first added it (around 1990, I think :-) I wasn't very
> attuned yet to the problems it could cause.

Fire-up the time machine?


Raymond


P.S.  The current behavior seems to be deeply embedded:

int PyObject_HasAttr(PyObject *o, PyObject *attr_name)
Returns 1 if o has the attribute attr_name, and 0 otherwise. This is equivalent to the Python expression hasattr(o, attr_name). This function always succeeds.
int PyObject_HasAttrString(PyObject *o, const char *attr_name)
Returns 1 if o has the attribute attr_name, and 0 otherwise. This is equivalent to the Python expression hasattr(o, attr_name). This function always succeeds.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100823/183721a7/attachment.html>

From benjamin at python.org  Mon Aug 23 22:45:58 2010
From: benjamin at python.org (Benjamin Peterson)
Date: Mon, 23 Aug 2010 15:45:58 -0500
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <46A37D14-D024-4CF8-9BED-E87B69734B8C@gmail.com>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
	<2C284C09-3819-4858-A75A-34597DD668B7@gmail.com>
	<AANLkTinz225t6xO-KH04FiaSPqJ6G9x9JhQ5adMi9_yT@mail.gmail.com>
	<46A37D14-D024-4CF8-9BED-E87B69734B8C@gmail.com>
Message-ID: <AANLkTimUHgb1sc8VcD3=rts5YoGkOLmXqUQqQEdxzBH=@mail.gmail.com>

2010/8/23 Raymond Hettinger <raymond.hettinger at gmail.com>:
> I don't have a specific proposal in mind. ?My main questions are
> * Is there anything that hasattr(obj, key) can or should do that
> ??can't already be done with getattr(obj, key, None)?
> ??If not,?do we really need to change anything?

For one, it's annoying when "key" can be None.

> * Why do people typically use hasattr() instead getattr()?
> ?? Aren't they are really trying to just determine
> ?? whether a key exists somewhere in the MRO?
> ?? If so, then doing anything more than that is probably?a surprise.

It's generally more convenient that getattr(obj, "blah", None) is not None.

>
> P.S. ?The current behavior seems to be deeply embedded:

Well, that's what happens when a behavior is added in 1990. :)



-- 
Regards,
Benjamin

From raymond.hettinger at gmail.com  Mon Aug 23 22:46:48 2010
From: raymond.hettinger at gmail.com (Raymond Hettinger)
Date: Mon, 23 Aug 2010 13:46:48 -0700
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <AANLkTinzZ40ykb+JHFFJ9W=4ww5AwiLnd=_s5pVgqVaN@mail.gmail.com>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
	<2C284C09-3819-4858-A75A-34597DD668B7@gmail.com>
	<AANLkTimFeoZsRdUfWfhSyievK_819KFRoqDO2H3sc2JN@mail.gmail.com>
	<4C72D552.2030306@voidspace.org.uk>
	<AANLkTinzZ40ykb+JHFFJ9W=4ww5AwiLnd=_s5pVgqVaN@mail.gmail.com>
Message-ID: <65FC8A3B-F9AF-4ED9-B63C-41335EF49E1A@gmail.com>


On Aug 23, 2010, at 1:13 PM, Benjamin Peterson wrote:

> 2010/8/23 Michael Foord <fuzzyman at voidspace.org.uk>:
>> To me hasattr *looks* like a passive introspection function, and the fact
>> that it can trigger arbitrary code execution is unfortunate - especially
>> because a full workaround is pretty arcane.

Well said.  The surprise to me in the OP's example was that
the property() was executed.  Regular methods aren't run
by hasattr() so it's hard to remember that when writing code using hasattr().

That is especially unfortunate because someone turning a regular
attribute into a property may be doing so long after client code has
been written (IIRC, that was a key use case for properties).  
IOW, the user of the hasattr() may have had no way
of knowing that an exception could ever be raised
(because it is perfectly safe with regular attributes and methods).


> That's the danger of a dynamic language like Python. Even dir() can
> now trigger things like that.

That's not a honking good thing.
I suggest we don't do more of that.



Raymond


From raymond.hettinger at gmail.com  Mon Aug 23 22:50:11 2010
From: raymond.hettinger at gmail.com (Raymond Hettinger)
Date: Mon, 23 Aug 2010 13:50:11 -0700
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <AANLkTimUHgb1sc8VcD3=rts5YoGkOLmXqUQqQEdxzBH=@mail.gmail.com>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
	<2C284C09-3819-4858-A75A-34597DD668B7@gmail.com>
	<AANLkTinz225t6xO-KH04FiaSPqJ6G9x9JhQ5adMi9_yT@mail.gmail.com>
	<46A37D14-D024-4CF8-9BED-E87B69734B8C@gmail.com>
	<AANLkTimUHgb1sc8VcD3=rts5YoGkOLmXqUQqQEdxzBH=@mail.gmail.com>
Message-ID: <A18C3186-94A5-4EF0-8C69-046C8A15FEDF@gmail.com>


On Aug 23, 2010, at 1:45 PM, Benjamin Peterson wrote:

> 2010/8/23 Raymond Hettinger <raymond.hettinger at gmail.com>:
>> 
>> P.S.  The current behavior seems to be deeply embedded:
> 
> Well, that's what happens when a behavior is added in 1990. :)



More generally:  it is an API code smell whenever documentation
promises something like "this always succeeds"     ;-)


Raymond

From guido at python.org  Mon Aug 23 22:50:19 2010
From: guido at python.org (Guido van Rossum)
Date: Mon, 23 Aug 2010 13:50:19 -0700
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <46A37D14-D024-4CF8-9BED-E87B69734B8C@gmail.com>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
	<2C284C09-3819-4858-A75A-34597DD668B7@gmail.com>
	<AANLkTinz225t6xO-KH04FiaSPqJ6G9x9JhQ5adMi9_yT@mail.gmail.com>
	<46A37D14-D024-4CF8-9BED-E87B69734B8C@gmail.com>
Message-ID: <AANLkTikM4GZNn8Yc9c=4FkRm=ewa1DUmFff+tPw_PWsL@mail.gmail.com>

On Mon, Aug 23, 2010 at 1:33 PM, Raymond Hettinger <
raymond.hettinger at gmail.com> wrote:
>
> I don't have a specific proposal in mind.
>

That's why I called it scope creep. :-) Trust me, your proposal will not
lead to a quick and better replacement for hasattr(). (See several other
people's replies.)


> My main questions are
>
> * Is there anything that hasattr(obj, key) can or should do that
>   can't already be done with getattr(obj, key, None)?
>   If not, do we really need to change anything?
>

getattr(obj, 'key', None) returns None when obj.key exists and has the value
None. The workaround is ugly.

* Why do people typically use hasattr() instead getattr()?
>    Aren't they are really trying to just determine
>    whether a key exists somewhere in the MRO?
>    If so, then doing anything more than that is probably a surprise.
>

Most users who call hasattr() probably don't even know what MRO means. They
call hasattr() because they want to avoid a try/except clause. The reasons
they are not calling getattr(obj, key, None) could be many: never heard of
it, too obscure (it surely doesn't spell "has the attribute" like hasattr()
does to the beginning user), or (probably common) the actual attribute
access is in some other piece of code they are about to call but don't
control.


> I know my own uses of hasattr() do not expect any exceptions at all.
> It comes up in duck typing support different handling for different
> types of inputs.  If others are using it the same way, I think it is
> unlikely that they have unittests to cover the possibility that
> hasattr() would ever start raising exceptions.
>

It already raises *some* exceptions (those derived from BaseException but
not Exception). I think that change was a definite non-event.


> I can vouch that the reason hasattr() catches too many exceptions is
> that when I first added it (around 1990, I think :-) I wasn't very
> attuned yet to the problems it could cause.
>
>
> Fire-up the time machine?
>
>
> Raymond
>
>
> P.S.  The current behavior seems to be deeply embedded:
>

But note that hasattr() doesn't call those.

> int PyObject_HasAttr(PyObject <http://structures.html#PyObject>* *o*,
> PyObject <http://structures.html#PyObject>* *attr_name*)<#12aa0a7c7d265b64_PyObject_HasAttr>
> Returns 1 if *o* has the attribute *attr_name*, and 0 otherwise. This is
> equivalent to the Python expression hasattr(o, attr_name). This function
> always succeeds. int PyObject_HasAttrString(PyObject<http://structures.html#PyObject>
> * *o*, const char* *attr_name*) <#12aa0a7c7d265b64_PyObject_HasAttrString>
> Returns 1 if *o* has the attribute *attr_name*, and 0 otherwise. This is
> equivalent to the Python expression hasattr(o, attr_name). This function
> always succeeds.
>
>
>


-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100823/b84b221f/attachment.html>

From yselivanov at gmail.com  Mon Aug 23 22:50:42 2010
From: yselivanov at gmail.com (Yury Selivanov)
Date: Mon, 23 Aug 2010 16:50:42 -0400
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <46A37D14-D024-4CF8-9BED-E87B69734B8C@gmail.com>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
	<2C284C09-3819-4858-A75A-34597DD668B7@gmail.com>
	<AANLkTinz225t6xO-KH04FiaSPqJ6G9x9JhQ5adMi9_yT@mail.gmail.com>
	<46A37D14-D024-4CF8-9BED-E87B69734B8C@gmail.com>
Message-ID: <3B72F00B-E63F-4BB2-B659-ADC411B7FDAE@gmail.com>

On 2010-08-23, at 4:33 PM, Raymond Hettinger wrote:
> 
> On Aug 23, 2010, at 1:03 PM, Guido van Rossum wrote:
> 
>>> But hasattr() has a far different set of use cases, so we should explore
>>> an alternate solution to the problem.  The usual reason that people use
>>> hasattr() instead of getattr() is that they want to check for the presence of
>>> of a method/attribute without actually running it, binding it, or triggering
>>> any other behavior.
>>> 
>>> As your example shows, property() defeats this intent by actually executing
>>> the code.   A better behavior would not run the code at all.  It would check
>>> the dictionaries along the MRO but not execute any descriptors associated
>>> with a given key.
>>> 
>>> IMO, this is a much better solution, more in line with known use cases
>>> for hasattr().   If the proposed change when through, it would fail to
>>> address the common use case and cause people to start writing their
>>> own versions of hasattr() that just scan but do not run code.
>> 
>> Hm... That sounds like scope creep to me. Properties are supposed to
>> be cheap and idempotent. Trying to figure out whether an attribute
>> exists without using __getattr__ is fraught with problems -- as soon
>> as a class overrides __getattr__ or __getattribute__ you're hosed
>> anyway.
> 
> I don't have a specific proposal in mind.  My main questions are
> 
> * Is there anything that hasattr(obj, key) can or should do that
>   can't already be done with getattr(obj, key, None)? 
>   If not, do we really need to change anything?

OK, if my key has None value, how will you detect it with 'getattr'?

    ... marker = object()
    ... if (getattr(obj, key, marker) is not marker:

Like in the above?  Too much code.  Ugly code.  Just to hide the issue
under the carpet.

> * Why do people typically use hasattr() instead getattr()?  
>    Aren't they are really trying to just determine 
>    whether a key exists somewhere in the MRO?
>    If so, then doing anything more than that is probably a surprise.

My example in the initial email clearly showed that sometimes, key is 
in MRO, but 'hasattr' returns False.

For everything in any complicated system (which Python obviously is)
should be a strict protocol.  In case of properties this protocol is to
raise AttributeError if property is missing.

Everything else is a potential bug.  Current 'hasattr' just masks them.

-
Yury


From fuzzyman at voidspace.org.uk  Mon Aug 23 22:55:00 2010
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Mon, 23 Aug 2010 23:55:00 +0300
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <AANLkTinzZ40ykb+JHFFJ9W=4ww5AwiLnd=_s5pVgqVaN@mail.gmail.com>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>	<2C284C09-3819-4858-A75A-34597DD668B7@gmail.com>	<AANLkTimFeoZsRdUfWfhSyievK_819KFRoqDO2H3sc2JN@mail.gmail.com>	<4C72D552.2030306@voidspace.org.uk>
	<AANLkTinzZ40ykb+JHFFJ9W=4ww5AwiLnd=_s5pVgqVaN@mail.gmail.com>
Message-ID: <4C72E024.4080500@voidspace.org.uk>

  On 23/08/2010 23:13, Benjamin Peterson wrote:
> 2010/8/23 Michael Foord<fuzzyman at voidspace.org.uk>:
>> To me hasattr *looks* like a passive introspection function, and the fact
>> that it can trigger arbitrary code execution is unfortunate - especially
>> because a full workaround is pretty arcane.
> That's the danger of a dynamic language like Python. Even dir() can
> now trigger things like that.
>

Well yes. One of the reasons a full workaround is so arcane is that if 
you *really* don't want to trigger code execution you can't call dir...

(Otherwise name in dir(obj) is a reasonable approximation for 
hasattr(obj, name).)

Michael

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


From benjamin at python.org  Mon Aug 23 22:55:23 2010
From: benjamin at python.org (Benjamin Peterson)
Date: Mon, 23 Aug 2010 15:55:23 -0500
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <65FC8A3B-F9AF-4ED9-B63C-41335EF49E1A@gmail.com>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
	<2C284C09-3819-4858-A75A-34597DD668B7@gmail.com>
	<AANLkTimFeoZsRdUfWfhSyievK_819KFRoqDO2H3sc2JN@mail.gmail.com>
	<4C72D552.2030306@voidspace.org.uk>
	<AANLkTinzZ40ykb+JHFFJ9W=4ww5AwiLnd=_s5pVgqVaN@mail.gmail.com>
	<65FC8A3B-F9AF-4ED9-B63C-41335EF49E1A@gmail.com>
Message-ID: <AANLkTiniuGQpt6dS4wi1yUBcBP2GZPDdStzL39T-kkFt@mail.gmail.com>

2010/8/23 Raymond Hettinger <raymond.hettinger at gmail.com>:
>
> On Aug 23, 2010, at 1:13 PM, Benjamin Peterson wrote:
>
>> 2010/8/23 Michael Foord <fuzzyman at voidspace.org.uk>:
>>> To me hasattr *looks* like a passive introspection function, and the fact
>>> that it can trigger arbitrary code execution is unfortunate - especially
>>> because a full workaround is pretty arcane.

hasattr(x, "y") doesn't look any more passive to me the x.y.

>
> Well said. ?The surprise to me in the OP's example was that
> the property() was executed. ?Regular methods aren't run
> by hasattr() so it's hard to remember that when writing code using hasattr().

Hard to remember compared to what?

>
> That is especially unfortunate because someone turning a regular
> attribute into a property may be doing so long after client code has
> been written (IIRC, that was a key use case for properties).
> IOW, the user of the hasattr() may have had no way
> of knowing that an exception could ever be raised
> (because it is perfectly safe with regular attributes and methods).

Better to raise an exception into unexpecting code that to have subtly
different lookup rules between getattr and hasattr.


-- 
Regards,
Benjamin

From guido at python.org  Mon Aug 23 22:55:10 2010
From: guido at python.org (Guido van Rossum)
Date: Mon, 23 Aug 2010 13:55:10 -0700
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <A18C3186-94A5-4EF0-8C69-046C8A15FEDF@gmail.com>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
	<2C284C09-3819-4858-A75A-34597DD668B7@gmail.com>
	<AANLkTinz225t6xO-KH04FiaSPqJ6G9x9JhQ5adMi9_yT@mail.gmail.com>
	<46A37D14-D024-4CF8-9BED-E87B69734B8C@gmail.com>
	<AANLkTimUHgb1sc8VcD3=rts5YoGkOLmXqUQqQEdxzBH=@mail.gmail.com>
	<A18C3186-94A5-4EF0-8C69-046C8A15FEDF@gmail.com>
Message-ID: <AANLkTinK3kM-tuZjSEZ5NFdfgDYweDn8umWskohJ1E1p@mail.gmail.com>

On Mon, Aug 23, 2010 at 1:50 PM, Raymond Hettinger
<raymond.hettinger at gmail.com> wrote:
>
> On Aug 23, 2010, at 1:45 PM, Benjamin Peterson wrote:
>
> > 2010/8/23 Raymond Hettinger <raymond.hettinger at gmail.com>:
> >>
> >> P.S. ?The current behavior seems to be deeply embedded:
> >
> > Well, that's what happens when a behavior is added in 1990. :)
>
> More generally: ?it is an API code smell whenever documentation
> promises something like "this always succeeds" ? ? ;-)

Changing C APIs is even harder than changing Python API because you
can't add exceptions to something that wasn't returning exceptions
before. We did that for comparisons in the past and it was a pain (but
worth it). For these two little APIs I think it is not worth it,
though it may be worth it to create new APIs that *do* return
exceptions.

--
--Guido van Rossum (python.org/~guido)

From benjamin at python.org  Mon Aug 23 22:56:43 2010
From: benjamin at python.org (Benjamin Peterson)
Date: Mon, 23 Aug 2010 15:56:43 -0500
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <AANLkTinK3kM-tuZjSEZ5NFdfgDYweDn8umWskohJ1E1p@mail.gmail.com>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
	<2C284C09-3819-4858-A75A-34597DD668B7@gmail.com>
	<AANLkTinz225t6xO-KH04FiaSPqJ6G9x9JhQ5adMi9_yT@mail.gmail.com>
	<46A37D14-D024-4CF8-9BED-E87B69734B8C@gmail.com>
	<AANLkTimUHgb1sc8VcD3=rts5YoGkOLmXqUQqQEdxzBH=@mail.gmail.com>
	<A18C3186-94A5-4EF0-8C69-046C8A15FEDF@gmail.com>
	<AANLkTinK3kM-tuZjSEZ5NFdfgDYweDn8umWskohJ1E1p@mail.gmail.com>
Message-ID: <AANLkTimPqjXhuo6EbhKS7Rayn8E9QOqX7H21vTPr=nW4@mail.gmail.com>

2010/8/23 Guido van Rossum <guido at python.org>:
> Changing C APIs is even harder than changing Python API because you
> can't add exceptions to something that wasn't returning exceptions
> before. We did that for comparisons in the past and it was a pain (but
> worth it). For these two little APIs I think it is not worth it,
> though it may be worth it to create new APIs that *do* return
> exceptions.

+1 I propose we add PyObject_HasattrWithErrors to parallel
PyDict_GetItemWithErrors.


-- 
Regards,
Benjamin

From fuzzyman at voidspace.org.uk  Mon Aug 23 23:02:42 2010
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Tue, 24 Aug 2010 00:02:42 +0300
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <AANLkTiniuGQpt6dS4wi1yUBcBP2GZPDdStzL39T-kkFt@mail.gmail.com>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>	<2C284C09-3819-4858-A75A-34597DD668B7@gmail.com>	<AANLkTimFeoZsRdUfWfhSyievK_819KFRoqDO2H3sc2JN@mail.gmail.com>	<4C72D552.2030306@voidspace.org.uk>	<AANLkTinzZ40ykb+JHFFJ9W=4ww5AwiLnd=_s5pVgqVaN@mail.gmail.com>	<65FC8A3B-F9AF-4ED9-B63C-41335EF49E1A@gmail.com>
	<AANLkTiniuGQpt6dS4wi1yUBcBP2GZPDdStzL39T-kkFt@mail.gmail.com>
Message-ID: <4C72E1F2.2020209@voidspace.org.uk>

  On 23/08/2010 23:55, Benjamin Peterson wrote:
> 2010/8/23 Raymond Hettinger<raymond.hettinger at gmail.com>:
>> On Aug 23, 2010, at 1:13 PM, Benjamin Peterson wrote:
>>
>>> 2010/8/23 Michael Foord<fuzzyman at voidspace.org.uk>:
>>>> To me hasattr *looks* like a passive introspection function, and the fact
>>>> that it can trigger arbitrary code execution is unfortunate - especially
>>>> because a full workaround is pretty arcane.
> hasattr(x, "y") doesn't look any more passive to me the x.y.
One says "does this object have attribute y" the other fetches attribute 
y. I'm amazed they don't look different to you. Given Python's object 
model there is no reason that the first *should* fetch the attribute to 
determine that it is present, *except* for the dynamic attribute 
creation of __getattr__ and __getattribute__.

For properties there is *no reason* why code should be executed merely 
in order to discover if the attribute exists or not.

I'm in both camps though. As we *are* triggering code execution I don't 
think we should mask exceptions. I just wish we weren't triggering code 
execution unnecessarily.

Michael


>> Well said.  The surprise to me in the OP's example was that
>> the property() was executed.  Regular methods aren't run
>> by hasattr() so it's hard to remember that when writing code using hasattr().
> Hard to remember compared to what?
>
>> That is especially unfortunate because someone turning a regular
>> attribute into a property may be doing so long after client code has
>> been written (IIRC, that was a key use case for properties).
>> IOW, the user of the hasattr() may have had no way
>> of knowing that an exception could ever be raised
>> (because it is perfectly safe with regular attributes and methods).
> Better to raise an exception into unexpecting code that to have subtly
> different lookup rules between getattr and hasattr.
>
>


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


From benjamin at python.org  Mon Aug 23 23:05:00 2010
From: benjamin at python.org (Benjamin Peterson)
Date: Mon, 23 Aug 2010 16:05:00 -0500
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <4C72E1F2.2020209@voidspace.org.uk>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
	<2C284C09-3819-4858-A75A-34597DD668B7@gmail.com>
	<AANLkTimFeoZsRdUfWfhSyievK_819KFRoqDO2H3sc2JN@mail.gmail.com>
	<4C72D552.2030306@voidspace.org.uk>
	<AANLkTinzZ40ykb+JHFFJ9W=4ww5AwiLnd=_s5pVgqVaN@mail.gmail.com>
	<65FC8A3B-F9AF-4ED9-B63C-41335EF49E1A@gmail.com>
	<AANLkTiniuGQpt6dS4wi1yUBcBP2GZPDdStzL39T-kkFt@mail.gmail.com>
	<4C72E1F2.2020209@voidspace.org.uk>
Message-ID: <AANLkTimGMunx9uEJMqDrQYLjKAOmypWQoOuACLDpWkGQ@mail.gmail.com>

2010/8/23 Michael Foord <fuzzyman at voidspace.org.uk>:
> ?On 23/08/2010 23:55, Benjamin Peterson wrote:
>>
>> 2010/8/23 Raymond Hettinger<raymond.hettinger at gmail.com>:
>>>
>>> On Aug 23, 2010, at 1:13 PM, Benjamin Peterson wrote:
>>>
>>>> 2010/8/23 Michael Foord<fuzzyman at voidspace.org.uk>:
>>>>>
>>>>> To me hasattr *looks* like a passive introspection function, and the
>>>>> fact
>>>>> that it can trigger arbitrary code execution is unfortunate -
>>>>> especially
>>>>> because a full workaround is pretty arcane.
>>
>> hasattr(x, "y") doesn't look any more passive to me the x.y.
>
> One says "does this object have attribute y" the other fetches attribute y.
> I'm amazed they don't look different to you. Given Python's object model
> there is no reason that the first *should* fetch the attribute to determine
> that it is present, *except* for the dynamic attribute creation of
> __getattr__ and __getattribute__.

Actually, I'd say given Python's object model, you have to have the
attribute in hand to determine that it is present.

>
> For properties there is *no reason* why code should be executed merely in
> order to discover if the attribute exists or not.

Properties are allowed to raise AttributeError, so you technically
have to execute it.



-- 
Regards,
Benjamin

From fuzzyman at voidspace.org.uk  Mon Aug 23 23:09:06 2010
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Tue, 24 Aug 2010 00:09:06 +0300
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <AANLkTimGMunx9uEJMqDrQYLjKAOmypWQoOuACLDpWkGQ@mail.gmail.com>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>	<2C284C09-3819-4858-A75A-34597DD668B7@gmail.com>	<AANLkTimFeoZsRdUfWfhSyievK_819KFRoqDO2H3sc2JN@mail.gmail.com>	<4C72D552.2030306@voidspace.org.uk>	<AANLkTinzZ40ykb+JHFFJ9W=4ww5AwiLnd=_s5pVgqVaN@mail.gmail.com>	<65FC8A3B-F9AF-4ED9-B63C-41335EF49E1A@gmail.com>	<AANLkTiniuGQpt6dS4wi1yUBcBP2GZPDdStzL39T-kkFt@mail.gmail.com>	<4C72E1F2.2020209@voidspace.org.uk>
	<AANLkTimGMunx9uEJMqDrQYLjKAOmypWQoOuACLDpWkGQ@mail.gmail.com>
Message-ID: <4C72E372.5060201@voidspace.org.uk>

  On 24/08/2010 00:05, Benjamin Peterson wrote:
> 2010/8/23 Michael Foord<fuzzyman at voidspace.org.uk>:
>>   On 23/08/2010 23:55, Benjamin Peterson wrote:
>>> 2010/8/23 Raymond Hettinger<raymond.hettinger at gmail.com>:
>>>> On Aug 23, 2010, at 1:13 PM, Benjamin Peterson wrote:
>>>>
>>>>> 2010/8/23 Michael Foord<fuzzyman at voidspace.org.uk>:
>>>>>> To me hasattr *looks* like a passive introspection function, and the
>>>>>> fact
>>>>>> that it can trigger arbitrary code execution is unfortunate -
>>>>>> especially
>>>>>> because a full workaround is pretty arcane.
>>> hasattr(x, "y") doesn't look any more passive to me the x.y.
>> One says "does this object have attribute y" the other fetches attribute y.
>> I'm amazed they don't look different to you. Given Python's object model
>> there is no reason that the first *should* fetch the attribute to determine
>> that it is present, *except* for the dynamic attribute creation of
>> __getattr__ and __getattribute__.
> Actually, I'd say given Python's object model, you have to have the
> attribute in hand to determine that it is present.
>
>> For properties there is *no reason* why code should be executed merely in
>> order to discover if the attribute exists or not.
> Properties are allowed to raise AttributeError, so you technically
> have to execute it.
>
Properties are allowed to do whatever the heck they want. That doesn't 
mean that you have to execute code to determine whether they exist or not.

If fetching an attribute raises an AttributeError it doesn't mean that 
attribute doesn't exist (although I admit that at the moment this is 
exactly what hasattr uses to mean) it just means that fetching that 
attribute raised an AttributeError. Even if you allow other exceptions 
to propagate you are still left with the fact that an AttributeError 
raised as a bug will still be silenced and interpreted as meaning that 
hasattr should just return False.

Michael Foord

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


From benjamin at python.org  Mon Aug 23 23:12:50 2010
From: benjamin at python.org (Benjamin Peterson)
Date: Mon, 23 Aug 2010 16:12:50 -0500
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <4C72E372.5060201@voidspace.org.uk>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
	<2C284C09-3819-4858-A75A-34597DD668B7@gmail.com>
	<AANLkTimFeoZsRdUfWfhSyievK_819KFRoqDO2H3sc2JN@mail.gmail.com>
	<4C72D552.2030306@voidspace.org.uk>
	<AANLkTinzZ40ykb+JHFFJ9W=4ww5AwiLnd=_s5pVgqVaN@mail.gmail.com>
	<65FC8A3B-F9AF-4ED9-B63C-41335EF49E1A@gmail.com>
	<AANLkTiniuGQpt6dS4wi1yUBcBP2GZPDdStzL39T-kkFt@mail.gmail.com>
	<4C72E1F2.2020209@voidspace.org.uk>
	<AANLkTimGMunx9uEJMqDrQYLjKAOmypWQoOuACLDpWkGQ@mail.gmail.com>
	<4C72E372.5060201@voidspace.org.uk>
Message-ID: <AANLkTin4BbTdhg=Z4XhBnA2Bbki7TJmRQXtOUZuHr-eH@mail.gmail.com>

2010/8/23 Michael Foord <fuzzyman at voidspace.org.uk>:
> Properties are allowed to do whatever the heck they want. That doesn't mean
> that you have to execute code to determine whether they exist or not.

I thought you were trying to determine whether the attribute exists
not the property.
>
> If fetching an attribute raises an AttributeError it doesn't mean that
> attribute doesn't exist (although I admit that at the moment this is exactly
> what hasattr uses to mean) it just means that fetching that attribute raised
> an AttributeError. Even if you allow other exceptions to propagate you are
> still left with the fact that an AttributeError raised as a bug will still
> be silenced and interpreted as meaning that hasattr should just return
> False.

Raised as a bug? Is this not a valid pattern?

@property
def myprop(self):
    if not self.myprop_support:
        raise AttributeError("myprop")



-- 
Regards,
Benjamin

From yselivanov at gmail.com  Mon Aug 23 23:22:55 2010
From: yselivanov at gmail.com (Yury Selivanov)
Date: Mon, 23 Aug 2010 17:22:55 -0400
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <4C72E1F2.2020209@voidspace.org.uk>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>	<2C284C09-3819-4858-A75A-34597DD668B7@gmail.com>	<AANLkTimFeoZsRdUfWfhSyievK_819KFRoqDO2H3sc2JN@mail.gmail.com>	<4C72D552.2030306@voidspace.org.uk>	<AANLkTinzZ40ykb+JHFFJ9W=4ww5AwiLnd=_s5pVgqVaN@mail.gmail.com>	<65FC8A3B-F9AF-4ED9-B63C-41335EF49E1A@gmail.com>
	<AANLkTiniuGQpt6dS4wi1yUBcBP2GZPDdStzL39T-kkFt@mail.gmail.com>
	<4C72E1F2.2020209@voidspace.org.uk>
Message-ID: <44CF7603-7F55-4AA5-8C61-F0E34D0D0EE2@gmail.com>

On 2010-08-23, at 5:02 PM, Michael Foord wrote:

> On 23/08/2010 23:55, Benjamin Peterson wrote:
>> 2010/8/23 Raymond Hettinger<raymond.hettinger at gmail.com>:
>>> On Aug 23, 2010, at 1:13 PM, Benjamin Peterson wrote:
>>> 
>>>> 2010/8/23 Michael Foord<fuzzyman at voidspace.org.uk>:
>>>>> To me hasattr *looks* like a passive introspection function, and the fact
>>>>> that it can trigger arbitrary code execution is unfortunate - especially
>>>>> because a full workaround is pretty arcane.
>> hasattr(x, "y") doesn't look any more passive to me the x.y.
> One says "does this object have attribute y" the other fetches attribute y. I'm amazed they don't look different to you. Given Python's object model there is no reason that the first *should* fetch the attribute to determine that it is present, *except* for the dynamic attribute creation of __getattr__ and __getattribute__.

As I understand the only possible way to make 'hasattr' work as it name indicates (i.e. just check if attribute exists, not run it), is to add another magic method(s?) to the existing __getattr__ and __getattribute__ which will tell whether attribute exists or not, and by default this method would mimic current 'hasattr' behaviour.

-
Yury


From yselivanov at gmail.com  Mon Aug 23 23:26:57 2010
From: yselivanov at gmail.com (Yury Selivanov)
Date: Mon, 23 Aug 2010 17:26:57 -0400
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <44CF7603-7F55-4AA5-8C61-F0E34D0D0EE2@gmail.com>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>	<2C284C09-3819-4858-A75A-34597DD668B7@gmail.com>	<AANLkTimFeoZsRdUfWfhSyievK_819KFRoqDO2H3sc2JN@mail.gmail.com>	<4C72D552.2030306@voidspace.org.uk>	<AANLkTinzZ40ykb+JHFFJ9W=4ww5AwiLnd=_s5pVgqVaN@mail.gmail.com>	<65FC8A3B-F9AF-4ED9-B63C-41335EF49E1A@gmail.com>
	<AANLkTiniuGQpt6dS4wi1yUBcBP2GZPDdStzL39T-kkFt@mail.gmail.com>
	<4C72E1F2.2020209@voidspace.org.uk>
	<44CF7603-7F55-4AA5-8C61-F0E34D0D0EE2@gmail.com>
Message-ID: <E2EA4060-3482-45AC-813B-8BDA097C9B64@gmail.com>

On 2010-08-23, at 5:22 PM, Yury Selivanov wrote:

> On 2010-08-23, at 5:02 PM, Michael Foord wrote:
> 
>> On 23/08/2010 23:55, Benjamin Peterson wrote:
>>> 2010/8/23 Raymond Hettinger<raymond.hettinger at gmail.com>:
>>>> On Aug 23, 2010, at 1:13 PM, Benjamin Peterson wrote:
>>>> 
>>>>> 2010/8/23 Michael Foord<fuzzyman at voidspace.org.uk>:
>>>>>> To me hasattr *looks* like a passive introspection function, and the fact
>>>>>> that it can trigger arbitrary code execution is unfortunate - especially
>>>>>> because a full workaround is pretty arcane.
>>> hasattr(x, "y") doesn't look any more passive to me the x.y.
>> One says "does this object have attribute y" the other fetches attribute y. I'm amazed they don't look different to you. Given Python's object model there is no reason that the first *should* fetch the attribute to determine that it is present, *except* for the dynamic attribute creation of __getattr__ and __getattribute__.
> 
> As I understand the only possible way to make 'hasattr' work as it name indicates (i.e. just check if attribute exists, not run it), is to add another magic method(s?) to the existing __getattr__ and __getattribute__ which will tell whether attribute exists or not, and by default this method would mimic current 'hasattr' behaviour.

I'm not sure we should do this, but if such method exists, let's call it __hasattribute__, ORMs, for instance, probably would benefit.

-
Yury

From ncoghlan at gmail.com  Mon Aug 23 23:40:32 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 24 Aug 2010 07:40:32 +1000
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <4C72E372.5060201@voidspace.org.uk>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
	<2C284C09-3819-4858-A75A-34597DD668B7@gmail.com>
	<AANLkTimFeoZsRdUfWfhSyievK_819KFRoqDO2H3sc2JN@mail.gmail.com>
	<4C72D552.2030306@voidspace.org.uk>
	<AANLkTinzZ40ykb+JHFFJ9W=4ww5AwiLnd=_s5pVgqVaN@mail.gmail.com>
	<65FC8A3B-F9AF-4ED9-B63C-41335EF49E1A@gmail.com>
	<AANLkTiniuGQpt6dS4wi1yUBcBP2GZPDdStzL39T-kkFt@mail.gmail.com>
	<4C72E1F2.2020209@voidspace.org.uk>
	<AANLkTimGMunx9uEJMqDrQYLjKAOmypWQoOuACLDpWkGQ@mail.gmail.com>
	<4C72E372.5060201@voidspace.org.uk>
Message-ID: <AANLkTiniWduAnWfmw+rV06fWAUYGNj4USce_cTOsoBgW@mail.gmail.com>

> Properties are allowed to do whatever the heck they want. That doesn't mean
> that you have to execute code to determine whether they exist or not.

If you don't want to execute properties, do the lookup on the type,
not the instance (obviously, you know the dance you need to do, since
you've linked the code where you did it). Having apparently simple
query operations like hasattr/getattr/len/etc execute arbitrary code
is where much of the language's flexibility comes from, so I don't see
how it can really be surprising when it happens.

To me, Python's definition of an object having an attribute is "Object
x has an attribute y if x.y does not raise AttributeError". That means
it can't figure out whether or not the attribute exists without
actually attempting to retrieve it. There are a few places where we
instead use a heuristic that says an attribute *probably* exists if it
appears in the instance dictionary, or in the dictionary of one of the
types in the MRO, and magic methods have the rule that they must be
defined on the type rather than the instance in order to count from
the interpreter's point of view, but neither of those things change
the basic definition.

For the record, +1 on narrowing the scope of the exception suppression
in hasattr() to only AttributeError, and adding new C API functions
that expose the new behaviour. (I've actually long assumed that
AttributeError *was* the only thing suppressed by hasattr()).

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From fuzzyman at voidspace.org.uk  Mon Aug 23 23:49:16 2010
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Tue, 24 Aug 2010 00:49:16 +0300
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <AANLkTiniWduAnWfmw+rV06fWAUYGNj4USce_cTOsoBgW@mail.gmail.com>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>	<2C284C09-3819-4858-A75A-34597DD668B7@gmail.com>	<AANLkTimFeoZsRdUfWfhSyievK_819KFRoqDO2H3sc2JN@mail.gmail.com>	<4C72D552.2030306@voidspace.org.uk>	<AANLkTinzZ40ykb+JHFFJ9W=4ww5AwiLnd=_s5pVgqVaN@mail.gmail.com>	<65FC8A3B-F9AF-4ED9-B63C-41335EF49E1A@gmail.com>	<AANLkTiniuGQpt6dS4wi1yUBcBP2GZPDdStzL39T-kkFt@mail.gmail.com>	<4C72E1F2.2020209@voidspace.org.uk>	<AANLkTimGMunx9uEJMqDrQYLjKAOmypWQoOuACLDpWkGQ@mail.gmail.com>	<4C72E372.5060201@voidspace.org.uk>
	<AANLkTiniWduAnWfmw+rV06fWAUYGNj4USce_cTOsoBgW@mail.gmail.com>
Message-ID: <4C72ECDC.8080104@voidspace.org.uk>

  On 24/08/2010 00:40, Nick Coghlan wrote:
>> Properties are allowed to do whatever the heck they want. That doesn't mean
>> that you have to execute code to determine whether they exist or not.
> If you don't want to execute properties, do the lookup on the type,
> not the instance (obviously, you know the dance you need to do, since
> you've linked the code where you did it). Having apparently simple
> query operations like hasattr/getattr/len/etc execute arbitrary code
> is where much of the language's flexibility comes from, so I don't see
> how it can really be surprising when it happens.

Certainly that is true for len. getattr obviously involves invoking code 
if you are fetching a property or descriptor. No idea how you conclude 
that hasattr executing code adds flexibility to the language though.

Yes I know the dance (walking the mro fetching the attribute out of the 
appropriate type __dict__ or the instance dict - or looking on the 
metaclass if the object you are introspecting is a type itself), it is 
just not trivial - which is why I think it is a shame that people are 
forced to implement it just to ask if a member exists without triggering 
code execution.

> To me, Python's definition of an object having an attribute is "Object
> x has an attribute y if x.y does not raise AttributeError".

Right, and to me Python's object model (the lookup rules hinted at 
above) define whether or not an object "has an attribute" or not. We 
just disagree on this.

However, it is irrelevant so not really worth continuing the discussion. 
Changing hasattr in this way would be backwards incompatible and so 
cannot be done. Doesn't mean I have to like it though. :-)

Michael

> That means
> it can't figure out whether or not the attribute exists without
> actually attempting to retrieve it. There are a few places where we
> instead use a heuristic that says an attribute *probably* exists if it
> appears in the instance dictionary, or in the dictionary of one of the
> types in the MRO, and magic methods have the rule that they must be
> defined on the type rather than the instance in order to count from
> the interpreter's point of view, but neither of those things change
> the basic definition.
>
> For the record, +1 on narrowing the scope of the exception suppression
> in hasattr() to only AttributeError, and adding new C API functions
> that expose the new behaviour. (I've actually long assumed that
> AttributeError *was* the only thing suppressed by hasattr()).
>
> Cheers,
> Nick.
>


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


From benjamin at python.org  Mon Aug 23 23:50:50 2010
From: benjamin at python.org (Benjamin Peterson)
Date: Mon, 23 Aug 2010 16:50:50 -0500
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <4C72ECDC.8080104@voidspace.org.uk>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
	<2C284C09-3819-4858-A75A-34597DD668B7@gmail.com>
	<AANLkTimFeoZsRdUfWfhSyievK_819KFRoqDO2H3sc2JN@mail.gmail.com>
	<4C72D552.2030306@voidspace.org.uk>
	<AANLkTinzZ40ykb+JHFFJ9W=4ww5AwiLnd=_s5pVgqVaN@mail.gmail.com>
	<65FC8A3B-F9AF-4ED9-B63C-41335EF49E1A@gmail.com>
	<AANLkTiniuGQpt6dS4wi1yUBcBP2GZPDdStzL39T-kkFt@mail.gmail.com>
	<4C72E1F2.2020209@voidspace.org.uk>
	<AANLkTimGMunx9uEJMqDrQYLjKAOmypWQoOuACLDpWkGQ@mail.gmail.com>
	<4C72E372.5060201@voidspace.org.uk>
	<AANLkTiniWduAnWfmw+rV06fWAUYGNj4USce_cTOsoBgW@mail.gmail.com>
	<4C72ECDC.8080104@voidspace.org.uk>
Message-ID: <AANLkTimi3Tjsr9J7LmK=dfbLqLMpoNrO+y0YUhTUVyQs@mail.gmail.com>

2010/8/23 Michael Foord <fuzzyman at voidspace.org.uk>:
> ?On 24/08/2010 00:40, Nick Coghlan wrote:
>>>
>>> Properties are allowed to do whatever the heck they want. That doesn't
>>> mean
>>> that you have to execute code to determine whether they exist or not.
>>
>> If you don't want to execute properties, do the lookup on the type,
>> not the instance (obviously, you know the dance you need to do, since
>> you've linked the code where you did it). Having apparently simple
>> query operations like hasattr/getattr/len/etc execute arbitrary code
>> is where much of the language's flexibility comes from, so I don't see
>> how it can really be surprising when it happens.
>
> Certainly that is true for len. getattr obviously involves invoking code if
> you are fetching a property or descriptor. No idea how you conclude that
> hasattr executing code adds flexibility to the language though.
>
> Yes I know the dance (walking the mro fetching the attribute out of the
> appropriate type __dict__ or the instance dict - or looking on the metaclass
> if the object you are introspecting is a type itself), it is just not
> trivial - which is why I think it is a shame that people are forced to
> implement it just to ask if a member exists without triggering code
> execution.

Sounds like something for a new function.



-- 
Regards,
Benjamin

From guido at python.org  Tue Aug 24 00:00:41 2010
From: guido at python.org (Guido van Rossum)
Date: Mon, 23 Aug 2010 15:00:41 -0700
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <44CF7603-7F55-4AA5-8C61-F0E34D0D0EE2@gmail.com>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
	<2C284C09-3819-4858-A75A-34597DD668B7@gmail.com>
	<AANLkTimFeoZsRdUfWfhSyievK_819KFRoqDO2H3sc2JN@mail.gmail.com>
	<4C72D552.2030306@voidspace.org.uk>
	<AANLkTinzZ40ykb+JHFFJ9W=4ww5AwiLnd=_s5pVgqVaN@mail.gmail.com>
	<65FC8A3B-F9AF-4ED9-B63C-41335EF49E1A@gmail.com>
	<AANLkTiniuGQpt6dS4wi1yUBcBP2GZPDdStzL39T-kkFt@mail.gmail.com>
	<4C72E1F2.2020209@voidspace.org.uk>
	<44CF7603-7F55-4AA5-8C61-F0E34D0D0EE2@gmail.com>
Message-ID: <AANLkTikAXvBq9dL7uj9k_+w7BgUQ+UK4oPpWZoqhHBwf@mail.gmail.com>

On Mon, Aug 23, 2010 at 2:22 PM, Yury Selivanov <yselivanov at gmail.com> wrote:
> As I understand the only possible way to make 'hasattr' work as it name indicates (i.e. just check if attribute exists, not run it), is to add another magic method(s?) to the existing __getattr__ and __getattribute__ which will tell whether attribute exists or not, and by default this method would mimic current 'hasattr' behaviour.

You nailed it. At the lowest level (either in C or in Python) there is
no way to check for an attribute's presence without getting its value.
This has so far been fundamental, and everything else is just
appearances.

I propose that this is good enough and that we should at this point
not try to invent another protocol, just decide whether hasattr() can
be fixed (and leaving PyObject_HasAttr*() alone).

-- 
--Guido van Rossum (python.org/~guido)

From yselivanov at gmail.com  Tue Aug 24 00:12:09 2010
From: yselivanov at gmail.com (Yury Selivanov)
Date: Mon, 23 Aug 2010 18:12:09 -0400
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <AANLkTikAXvBq9dL7uj9k_+w7BgUQ+UK4oPpWZoqhHBwf@mail.gmail.com>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
	<2C284C09-3819-4858-A75A-34597DD668B7@gmail.com>
	<AANLkTimFeoZsRdUfWfhSyievK_819KFRoqDO2H3sc2JN@mail.gmail.com>
	<4C72D552.2030306@voidspace.org.uk>
	<AANLkTinzZ40ykb+JHFFJ9W=4ww5AwiLnd=_s5pVgqVaN@mail.gmail.com>
	<65FC8A3B-F9AF-4ED9-B63C-41335EF49E1A@gmail.com>
	<AANLkTiniuGQpt6dS4wi1yUBcBP2GZPDdStzL39T-kkFt@mail.gmail.com>
	<4C72E1F2.2020209@voidspace.org.uk>
	<44CF7603-7F55-4AA5-8C61-F0E34D0D0EE2@gmail.com>
	<AANLkTikAXvBq9dL7uj9k_+w7BgUQ+UK4oPpWZoqhHBwf@mail.gmail.com>
Message-ID: <BD2CCE2A-7E62-4D39-AF09-0CC6809F8CAB@gmail.com>

> On 2010-08-23, at 6:00 PM, Guido van Rossum wrote:
> On Mon, Aug 23, 2010 at 2:22 PM, Yury Selivanov <yselivanov at gmail.com> wrote:
>> As I understand the only possible way to make 'hasattr' work as it name indicates (i.e. just check if attribute exists, not run it), is to add another magic method(s?) to the existing __getattr__ and __getattribute__ which will tell whether attribute exists or not, and by default this method would mimic current 'hasattr' behaviour.
> 
> You nailed it. At the lowest level (either in C or in Python) there is
> no way to check for an attribute's presence without getting its value.
> This has so far been fundamental, and everything else is just
> appearances.
> 
> I propose that this is good enough and that we should at this point
> not try to invent another protocol, just decide whether hasattr() can
> be fixed (and leaving PyObject_HasAttr*() alone).

BTW, is it possible to add new magic method __hasattr__?  Maybe not
in Python 3.2, but in general.

The more I think about it the more I like the idea.  By default, 'hasattr'
would check MRO for the attribute, if not found - check for __hasattr__,
if not found - fallback to the current schema with 'getattr'.

This would not break any current code, but open a lot of potential 
(especially for things that implement some lazy loading protocols).

From the performance point of view, I believe it shouldn't change much,
as current 'hasattr' which uses 'getattr' which calls __getattr(ibute)__ 
methods.

I know this is much more then just fixing exception swallowing, but this
is somewhat required functionality to complete the current dynamism 
python offers.

-
Yury

From ncoghlan at gmail.com  Tue Aug 24 00:15:19 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 24 Aug 2010 08:15:19 +1000
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <AANLkTiniWduAnWfmw+rV06fWAUYGNj4USce_cTOsoBgW@mail.gmail.com>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
	<2C284C09-3819-4858-A75A-34597DD668B7@gmail.com>
	<AANLkTimFeoZsRdUfWfhSyievK_819KFRoqDO2H3sc2JN@mail.gmail.com>
	<4C72D552.2030306@voidspace.org.uk>
	<AANLkTinzZ40ykb+JHFFJ9W=4ww5AwiLnd=_s5pVgqVaN@mail.gmail.com>
	<65FC8A3B-F9AF-4ED9-B63C-41335EF49E1A@gmail.com>
	<AANLkTiniuGQpt6dS4wi1yUBcBP2GZPDdStzL39T-kkFt@mail.gmail.com>
	<4C72E1F2.2020209@voidspace.org.uk>
	<AANLkTimGMunx9uEJMqDrQYLjKAOmypWQoOuACLDpWkGQ@mail.gmail.com>
	<4C72E372.5060201@voidspace.org.uk>
	<AANLkTiniWduAnWfmw+rV06fWAUYGNj4USce_cTOsoBgW@mail.gmail.com>
Message-ID: <AANLkTikSKdYRu5kJDxLT-m4Y_bM33mY+kWaBawyreTRo@mail.gmail.com>

On Tue, Aug 24, 2010 at 7:40 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> Properties are allowed to do whatever the heck they want. That doesn't mean
>> that you have to execute code to determine whether they exist or not.
>
> If you don't want to execute properties, do the lookup on the type,
> not the instance (obviously, you know the dance you need to do, since
> you've linked the code where you did it). Having apparently simple
> query operations like hasattr/getattr/len/etc execute arbitrary code
> is where much of the language's flexibility comes from, so I don't see
> how it can really be surprising when it happens.

Now, it may be worth considering an addition to the inspect module
that was basically:

def getattr_static(obj, attr):
    """Retrieve attributes without triggering dynamic lookup via the
descriptor protocol,
        __getattr__ or __getattribute__.

        Note: this function may not be able to retrieve all attributes
reported by dir(obj)
    """
    try:
        instance_dict = object.__getattribute__(obj, "__dict__")
    except AttributeError:
        pass
    else:
        if attr in instance_dict:
            return instance_dict[attr]
    for entry in getmro(obj.__class__):
        try:
            return entry.__dict__[attr]
        except AttributeError:
            pass

(not needing to deal with classic classes simplifies things a bit)

So, allowing for the fact that dir() may report attributes that can
only be found via dynamic lookup, your get_docstrings example could
become something like:

def get_docstrings(obj):
    try:
        members = dir(obj)
    except Exception:
        members = []
    for member in members:
        try:
            doc = getattr_static(obj, member).__doc__
        except AttributeError:
            doc = None
        yield member, doc

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From benjamin at python.org  Tue Aug 24 00:17:16 2010
From: benjamin at python.org (Benjamin Peterson)
Date: Mon, 23 Aug 2010 17:17:16 -0500
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <BD2CCE2A-7E62-4D39-AF09-0CC6809F8CAB@gmail.com>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
	<2C284C09-3819-4858-A75A-34597DD668B7@gmail.com>
	<AANLkTimFeoZsRdUfWfhSyievK_819KFRoqDO2H3sc2JN@mail.gmail.com>
	<4C72D552.2030306@voidspace.org.uk>
	<AANLkTinzZ40ykb+JHFFJ9W=4ww5AwiLnd=_s5pVgqVaN@mail.gmail.com>
	<65FC8A3B-F9AF-4ED9-B63C-41335EF49E1A@gmail.com>
	<AANLkTiniuGQpt6dS4wi1yUBcBP2GZPDdStzL39T-kkFt@mail.gmail.com>
	<4C72E1F2.2020209@voidspace.org.uk>
	<44CF7603-7F55-4AA5-8C61-F0E34D0D0EE2@gmail.com>
	<AANLkTikAXvBq9dL7uj9k_+w7BgUQ+UK4oPpWZoqhHBwf@mail.gmail.com>
	<BD2CCE2A-7E62-4D39-AF09-0CC6809F8CAB@gmail.com>
Message-ID: <AANLkTimM-02=+dfTW=zRdRM3Cryqy35jeiz6aRc4y4k8@mail.gmail.com>

2010/8/23 Yury Selivanov <yselivanov at gmail.com>:
>> On 2010-08-23, at 6:00 PM, Guido van Rossum wrote:
>> On Mon, Aug 23, 2010 at 2:22 PM, Yury Selivanov <yselivanov at gmail.com> wrote:
> BTW, is it possible to add new magic method __hasattr__? ?Maybe not
> in Python 3.2, but in general.

-1 The whole point of hasattr() is that getattr() on that attribute
would return something. Let's not destroy that.

-- 
Regards,
Benjamin

From ncoghlan at gmail.com  Tue Aug 24 00:17:20 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 24 Aug 2010 08:17:20 +1000
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <4C72ECDC.8080104@voidspace.org.uk>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
	<2C284C09-3819-4858-A75A-34597DD668B7@gmail.com>
	<AANLkTimFeoZsRdUfWfhSyievK_819KFRoqDO2H3sc2JN@mail.gmail.com>
	<4C72D552.2030306@voidspace.org.uk>
	<AANLkTinzZ40ykb+JHFFJ9W=4ww5AwiLnd=_s5pVgqVaN@mail.gmail.com>
	<65FC8A3B-F9AF-4ED9-B63C-41335EF49E1A@gmail.com>
	<AANLkTiniuGQpt6dS4wi1yUBcBP2GZPDdStzL39T-kkFt@mail.gmail.com>
	<4C72E1F2.2020209@voidspace.org.uk>
	<AANLkTimGMunx9uEJMqDrQYLjKAOmypWQoOuACLDpWkGQ@mail.gmail.com>
	<4C72E372.5060201@voidspace.org.uk>
	<AANLkTiniWduAnWfmw+rV06fWAUYGNj4USce_cTOsoBgW@mail.gmail.com>
	<4C72ECDC.8080104@voidspace.org.uk>
Message-ID: <AANLkTim9Po1Db199MJ8h4tvoazpBN9rtGjZB4qC4JNmi@mail.gmail.com>

On Tue, Aug 24, 2010 at 7:49 AM, Michael Foord
<fuzzyman at voidspace.org.uk> wrote:
> Certainly that is true for len. getattr obviously involves invoking code if
> you are fetching a property or descriptor. No idea how you conclude that
> hasattr executing code adds flexibility to the language though.

Proxy objects like the one in the weakref module don't work if
hasattr() doesn't implicitly invoke __getattr__.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From yselivanov at gmail.com  Tue Aug 24 00:22:31 2010
From: yselivanov at gmail.com (Yury Selivanov)
Date: Mon, 23 Aug 2010 18:22:31 -0400
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <AANLkTimM-02=+dfTW=zRdRM3Cryqy35jeiz6aRc4y4k8@mail.gmail.com>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
	<2C284C09-3819-4858-A75A-34597DD668B7@gmail.com>
	<AANLkTimFeoZsRdUfWfhSyievK_819KFRoqDO2H3sc2JN@mail.gmail.com>
	<4C72D552.2030306@voidspace.org.uk>
	<AANLkTinzZ40ykb+JHFFJ9W=4ww5AwiLnd=_s5pVgqVaN@mail.gmail.com>
	<65FC8A3B-F9AF-4ED9-B63C-41335EF49E1A@gmail.com>
	<AANLkTiniuGQpt6dS4wi1yUBcBP2GZPDdStzL39T-kkFt@mail.gmail.com>
	<4C72E1F2.2020209@voidspace.org.uk>
	<44CF7603-7F55-4AA5-8C61-F0E34D0D0EE2@gmail.com>
	<AANLkTikAXvBq9dL7uj9k_+w7BgUQ+UK4oPpWZoqhHBwf@mail.gmail.com>
	<BD2CCE2A-7E62-4D39-AF09-0CC6809F8CAB@gmail.com>
	<AANLkTimM-02=+dfTW=zRdRM3Cryqy35jeiz6aRc4y4k8@mail.gmail.com>
Message-ID: <13D815C6-248F-44FE-83B9-65C85685072A@gmail.com>

> On 2010-08-23, at 6:17 PM, Benjamin Peterson wrote:
> 2010/8/23 Yury Selivanov <yselivanov at gmail.com>:
>>> On 2010-08-23, at 6:00 PM, Guido van Rossum wrote:
>>> On Mon, Aug 23, 2010 at 2:22 PM, Yury Selivanov <yselivanov at gmail.com> wrote:
>> BTW, is it possible to add new magic method __hasattr__?  Maybe not
>> in Python 3.2, but in general.
> 
> -1 The whole point of hasattr() is that getattr() on that attribute
> would return something. Let's not destroy that.

By default, if you don't overload __hasattr__, it will do exactly that.

But let's imagine the situation in some ORM.  Sometimes, engine knows that
attribute exists even before executing it (which leads to querying DB), and
thus it is possible to return True in the overloaded __hasattr__.

Example:
... if hasattr(entity, 'title'): # <- __hasattr__ has the info in metadata,
                                 #    no query to DB
...     title = entity.title     # <- now, we can query the DB

So, the proposed magic method is not intended to change the protocol,
but to complement and enhance it.

-
Yury

From benjamin at python.org  Tue Aug 24 00:25:18 2010
From: benjamin at python.org (Benjamin Peterson)
Date: Mon, 23 Aug 2010 17:25:18 -0500
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <13D815C6-248F-44FE-83B9-65C85685072A@gmail.com>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
	<2C284C09-3819-4858-A75A-34597DD668B7@gmail.com>
	<AANLkTimFeoZsRdUfWfhSyievK_819KFRoqDO2H3sc2JN@mail.gmail.com>
	<4C72D552.2030306@voidspace.org.uk>
	<AANLkTinzZ40ykb+JHFFJ9W=4ww5AwiLnd=_s5pVgqVaN@mail.gmail.com>
	<65FC8A3B-F9AF-4ED9-B63C-41335EF49E1A@gmail.com>
	<AANLkTiniuGQpt6dS4wi1yUBcBP2GZPDdStzL39T-kkFt@mail.gmail.com>
	<4C72E1F2.2020209@voidspace.org.uk>
	<44CF7603-7F55-4AA5-8C61-F0E34D0D0EE2@gmail.com>
	<AANLkTikAXvBq9dL7uj9k_+w7BgUQ+UK4oPpWZoqhHBwf@mail.gmail.com>
	<BD2CCE2A-7E62-4D39-AF09-0CC6809F8CAB@gmail.com>
	<AANLkTimM-02=+dfTW=zRdRM3Cryqy35jeiz6aRc4y4k8@mail.gmail.com>
	<13D815C6-248F-44FE-83B9-65C85685072A@gmail.com>
Message-ID: <AANLkTinw-tk+CzJrkY63p74H5iEuSvHDuPn+6PH0XP7r@mail.gmail.com>

2010/8/23 Yury Selivanov <yselivanov at gmail.com>:
>> On 2010-08-23, at 6:17 PM, Benjamin Peterson wrote:
>> 2010/8/23 Yury Selivanov <yselivanov at gmail.com>:
>>>> On 2010-08-23, at 6:00 PM, Guido van Rossum wrote:
>>>> On Mon, Aug 23, 2010 at 2:22 PM, Yury Selivanov <yselivanov at gmail.com> wrote:
>>> BTW, is it possible to add new magic method __hasattr__? ?Maybe not
>>> in Python 3.2, but in general.
>>
>> -1 The whole point of hasattr() is that getattr() on that attribute
>> would return something. Let's not destroy that.
>
> By default, if you don't overload __hasattr__, it will do exactly that.
>
> But let's imagine the situation in some ORM. ?Sometimes, engine knows that
> attribute exists even before executing it (which leads to querying DB), and
> thus it is possible to return True in the overloaded __hasattr__.
>
> Example:
> ... if hasattr(entity, 'title'): # <- __hasattr__ has the info in metadata,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? # ? ?no query to DB
> ... ? ? title = entity.title ? ? # <- now, we can query the DB

In this case, I think it would make more sense to ask the model:
type(entity).has_property("title")

>
> So, the proposed magic method is not intended to change the protocol,
> but to complement and enhance it.

But it still raises the potential to break the relationship between
hasattr and getattr.

I think this should require a PEP.



-- 
Regards,
Benjamin

From ncoghlan at gmail.com  Tue Aug 24 00:25:03 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 24 Aug 2010 08:25:03 +1000
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <AANLkTikSKdYRu5kJDxLT-m4Y_bM33mY+kWaBawyreTRo@mail.gmail.com>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
	<2C284C09-3819-4858-A75A-34597DD668B7@gmail.com>
	<AANLkTimFeoZsRdUfWfhSyievK_819KFRoqDO2H3sc2JN@mail.gmail.com>
	<4C72D552.2030306@voidspace.org.uk>
	<AANLkTinzZ40ykb+JHFFJ9W=4ww5AwiLnd=_s5pVgqVaN@mail.gmail.com>
	<65FC8A3B-F9AF-4ED9-B63C-41335EF49E1A@gmail.com>
	<AANLkTiniuGQpt6dS4wi1yUBcBP2GZPDdStzL39T-kkFt@mail.gmail.com>
	<4C72E1F2.2020209@voidspace.org.uk>
	<AANLkTimGMunx9uEJMqDrQYLjKAOmypWQoOuACLDpWkGQ@mail.gmail.com>
	<4C72E372.5060201@voidspace.org.uk>
	<AANLkTiniWduAnWfmw+rV06fWAUYGNj4USce_cTOsoBgW@mail.gmail.com>
	<AANLkTikSKdYRu5kJDxLT-m4Y_bM33mY+kWaBawyreTRo@mail.gmail.com>
Message-ID: <AANLkTik8Ld2z-QsiT0=c0zWwUNyw_pAQkROMpUGJXHth@mail.gmail.com>

On Tue, Aug 24, 2010 at 8:15 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> Now, it may be worth considering an addition to the inspect module
> that was basically:
>
> def getattr_static(obj, attr):
> ? ?"""Retrieve attributes without triggering dynamic lookup via the
> descriptor protocol,
> ? ? ? ?__getattr__ or __getattribute__.
>
> ? ? ? ?Note: this function may not be able to retrieve all attributes
> reported by dir(obj)
> ? ?"""
> ? ?try:
> ? ? ? ?instance_dict = object.__getattribute__(obj, "__dict__")
> ? ?except AttributeError:
> ? ? ? ?pass
> ? ?else:
> ? ? ? ?if attr in instance_dict:
> ? ? ? ? ? ?return instance_dict[attr]
> ? ?for entry in getmro(obj.__class__):
> ? ? ? ?try:
> ? ? ? ? ? ?return entry.__dict__[attr]
> ? ? ? ?except AttributeError:
> ? ? ? ? ? ?pass

Second attempt with a default value parameter and correctly raising
AttributeError if not found:

_sentinel = object()
def getattr_static(obj, attr, default=_sentinel):
    """Retrieve attributes without triggering dynamic lookup via the
        descriptor protocol,  __getattr__ or __getattribute__.

        Note: this function may not be able to retrieve all attributes
        reported by dir(obj)
    """
    try:
        instance_dict = object.__getattribute__(obj, "__dict__")
    except AttributeError:
        pass
    else:
        if attr in instance_dict:
            return instance_dict[attr]
    for entry in getmro(obj.__class__):
        try:
            return entry.__dict__[attr]
        except AttributeError:
            pass
    if default is not _sentinel:
        return default
    raise AttributeError(attr)

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From pje at telecommunity.com  Tue Aug 24 00:39:03 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Mon, 23 Aug 2010 18:39:03 -0400
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <4C72E1F2.2020209@voidspace.org.uk>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
	<2C284C09-3819-4858-A75A-34597DD668B7@gmail.com>
	<AANLkTimFeoZsRdUfWfhSyievK_819KFRoqDO2H3sc2JN@mail.gmail.com>
	<4C72D552.2030306@voidspace.org.uk>
	<AANLkTinzZ40ykb+JHFFJ9W=4ww5AwiLnd=_s5pVgqVaN@mail.gmail.com>
	<65FC8A3B-F9AF-4ED9-B63C-41335EF49E1A@gmail.com>
	<AANLkTiniuGQpt6dS4wi1yUBcBP2GZPDdStzL39T-kkFt@mail.gmail.com>
	<4C72E1F2.2020209@voidspace.org.uk>
Message-ID: <20100823223911.24BA43A4108@sparrow.telecommunity.com>

At 12:02 AM 8/24/2010 +0300, Michael Foord wrote:
>For properties there is *no reason* why code should be executed 
>merely in order to discover if the attribute exists or not.

That depends on what you mean by "exists".  Note that a property 
might raise AttributeError to signal that the attribute is not 
currently set.  Likewise, unless you special case __slots__ 
descriptors, you can have the bizarre condition where hasattr() will 
return True, but getattr() will still raise an AttributeError.

The idea that you could determine the presence of an attribute on an 
object without executing that object's code is something that hasn't 
been practical since the birth of descriptors in Python 2.2.


>Yes I know the dance (walking the mro fetching the attribute out of 
>the appropriate type __dict__ or the instance dict - or looking on 
>the metaclass if the object you are introspecting is a type itself), 
>it is just not trivial - which is why I think it is a shame that 
>people are forced to implement it just to ask if a member exists 
>without triggering code execution.

Even if you implement it, you will get wrong answers in some 
cases.  __getattribute__ is allowed to throw out the entire algorithm 
you just described and replace it utterly with something else.

My ProxyTypes library makes use of that fact, for example, so if you 
actually attempted to inspect a proxy instance with your 
re-implemented "dance", your code will fail to notice what attributes 
the proxy actually has.


From ncoghlan at gmail.com  Tue Aug 24 00:39:37 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 24 Aug 2010 08:39:37 +1000
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <AANLkTinw-tk+CzJrkY63p74H5iEuSvHDuPn+6PH0XP7r@mail.gmail.com>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
	<2C284C09-3819-4858-A75A-34597DD668B7@gmail.com>
	<AANLkTimFeoZsRdUfWfhSyievK_819KFRoqDO2H3sc2JN@mail.gmail.com>
	<4C72D552.2030306@voidspace.org.uk>
	<AANLkTinzZ40ykb+JHFFJ9W=4ww5AwiLnd=_s5pVgqVaN@mail.gmail.com>
	<65FC8A3B-F9AF-4ED9-B63C-41335EF49E1A@gmail.com>
	<AANLkTiniuGQpt6dS4wi1yUBcBP2GZPDdStzL39T-kkFt@mail.gmail.com>
	<4C72E1F2.2020209@voidspace.org.uk>
	<44CF7603-7F55-4AA5-8C61-F0E34D0D0EE2@gmail.com>
	<AANLkTikAXvBq9dL7uj9k_+w7BgUQ+UK4oPpWZoqhHBwf@mail.gmail.com>
	<BD2CCE2A-7E62-4D39-AF09-0CC6809F8CAB@gmail.com>
	<AANLkTimM-02=+dfTW=zRdRM3Cryqy35jeiz6aRc4y4k8@mail.gmail.com>
	<13D815C6-248F-44FE-83B9-65C85685072A@gmail.com>
	<AANLkTinw-tk+CzJrkY63p74H5iEuSvHDuPn+6PH0XP7r@mail.gmail.com>
Message-ID: <AANLkTi=AaZHHjSzVo3wB90zW-4s2j0KRA3W7zVGaHt2O@mail.gmail.com>

On Tue, Aug 24, 2010 at 8:25 AM, Benjamin Peterson <benjamin at python.org> wrote:
> 2010/8/23 Yury Selivanov <yselivanov at gmail.com>:
>> So, the proposed magic method is not intended to change the protocol,
>> but to complement and enhance it.
>
> But it still raises the potential to break the relationship between
> hasattr and getattr.
>
> I think this should require a PEP.

Definitely needs a PEP, and will require some solid use cases to
explain why allowing optimisation of hasattr() is the right way to go.
Complexity isn't free, and I doubt the gains here will justify the
costs, but that's one of the things the PEP process is intended to
figure out.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From pje at telecommunity.com  Tue Aug 24 00:45:32 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Mon, 23 Aug 2010 18:45:32 -0400
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <BD2CCE2A-7E62-4D39-AF09-0CC6809F8CAB@gmail.com>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
	<2C284C09-3819-4858-A75A-34597DD668B7@gmail.com>
	<AANLkTimFeoZsRdUfWfhSyievK_819KFRoqDO2H3sc2JN@mail.gmail.com>
	<4C72D552.2030306@voidspace.org.uk>
	<AANLkTinzZ40ykb+JHFFJ9W=4ww5AwiLnd=_s5pVgqVaN@mail.gmail.com>
	<65FC8A3B-F9AF-4ED9-B63C-41335EF49E1A@gmail.com>
	<AANLkTiniuGQpt6dS4wi1yUBcBP2GZPDdStzL39T-kkFt@mail.gmail.com>
	<4C72E1F2.2020209@voidspace.org.uk>
	<44CF7603-7F55-4AA5-8C61-F0E34D0D0EE2@gmail.com>
	<AANLkTikAXvBq9dL7uj9k_+w7BgUQ+UK4oPpWZoqhHBwf@mail.gmail.com>
	<BD2CCE2A-7E62-4D39-AF09-0CC6809F8CAB@gmail.com>
Message-ID: <20100823224536.7E51F3A4108@sparrow.telecommunity.com>

At 06:12 PM 8/23/2010 -0400, Yury Selivanov wrote:
>BTW, is it possible to add new magic method __hasattr__?  Maybe not
>in Python 3.2, but in general.

In order to do this properly, you'd need to also add __has__ or 
__exists__ (or some such) to the descriptor protocol; otherwise you 
break descriptors' ability to operate independently of the class 
they're used in.  You would probably also need a __hasattribute__, in 
order to be able to properly synchronize with __getattr__/__getattribute__.

Seems like overkill to me, though, as I'm not sure how such a 
protocol actually helps ORM or persistence schemes (and I've written 
a few).  Pretty much, if you're trying to check for the existence of 
an attribute, you're probably about to be getting that attribute 
anyway.  (i.e. why query the existence of an attribute you *don't* 
intend to use?)


From barry at python.org  Tue Aug 24 00:47:39 2010
From: barry at python.org (Barry Warsaw)
Date: Mon, 23 Aug 2010 18:47:39 -0400
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <AANLkTimUHgb1sc8VcD3=rts5YoGkOLmXqUQqQEdxzBH=@mail.gmail.com>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
	<2C284C09-3819-4858-A75A-34597DD668B7@gmail.com>
	<AANLkTinz225t6xO-KH04FiaSPqJ6G9x9JhQ5adMi9_yT@mail.gmail.com>
	<46A37D14-D024-4CF8-9BED-E87B69734B8C@gmail.com>
	<AANLkTimUHgb1sc8VcD3=rts5YoGkOLmXqUQqQEdxzBH=@mail.gmail.com>
Message-ID: <20100823184739.40fcc7dd@heresy>

On Aug 23, 2010, at 03:45 PM, Benjamin Peterson wrote:

>It's generally more convenient that getattr(obj, "blah", None) is not
>None.

Clearly, the solution is a new builtin called 'Missing'.

<wink>
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100823/5286f3ad/attachment.pgp>

From guido at python.org  Tue Aug 24 00:49:46 2010
From: guido at python.org (Guido van Rossum)
Date: Mon, 23 Aug 2010 15:49:46 -0700
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <20100823224536.7E51F3A4108@sparrow.telecommunity.com>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
	<2C284C09-3819-4858-A75A-34597DD668B7@gmail.com>
	<AANLkTimFeoZsRdUfWfhSyievK_819KFRoqDO2H3sc2JN@mail.gmail.com>
	<4C72D552.2030306@voidspace.org.uk>
	<AANLkTinzZ40ykb+JHFFJ9W=4ww5AwiLnd=_s5pVgqVaN@mail.gmail.com>
	<65FC8A3B-F9AF-4ED9-B63C-41335EF49E1A@gmail.com>
	<AANLkTiniuGQpt6dS4wi1yUBcBP2GZPDdStzL39T-kkFt@mail.gmail.com>
	<4C72E1F2.2020209@voidspace.org.uk>
	<44CF7603-7F55-4AA5-8C61-F0E34D0D0EE2@gmail.com>
	<AANLkTikAXvBq9dL7uj9k_+w7BgUQ+UK4oPpWZoqhHBwf@mail.gmail.com>
	<BD2CCE2A-7E62-4D39-AF09-0CC6809F8CAB@gmail.com>
	<20100823224536.7E51F3A4108@sparrow.telecommunity.com>
Message-ID: <AANLkTimjb80ZRyhbBWEyDs6cNZ3=0WHYmfcsHjXCM2p4@mail.gmail.com>

On Mon, Aug 23, 2010 at 3:45 PM, P.J. Eby <pje at telecommunity.com> wrote:
> At 06:12 PM 8/23/2010 -0400, Yury Selivanov wrote:
>>
>> BTW, is it possible to add new magic method __hasattr__? ?Maybe not
>> in Python 3.2, but in general.
>
> In order to do this properly, you'd need to also add __has__ or __exists__
> (or some such) to the descriptor protocol; otherwise you break descriptors'
> ability to operate independently of the class they're used in. ?You would
> probably also need a __hasattribute__, in order to be able to properly
> synchronize with __getattr__/__getattribute__.
>
> Seems like overkill to me, though, as I'm not sure how such a protocol
> actually helps ORM or persistence schemes (and I've written a few). ?Pretty
> much, if you're trying to check for the existence of an attribute, you're
> probably about to be getting that attribute anyway. ?(i.e. why query the
> existence of an attribute you *don't* intend to use?)

Right. This sounds like way too big a gun to kill this particular
mosquito. If Yury wants to write a PEP I won't stop him, but I expect
that it will be rejected for want of important use cases compared to
the complexity of the solution. There just are too many places that
would be affected, for too little value.

So just be warned.

OTOH I still think that fixing hasattr() to be mroe like getattr(obj,
key, None) has a high value and a relative low risk.

-- 
--Guido van Rossum (python.org/~guido)

From ncoghlan at gmail.com  Tue Aug 24 00:15:19 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 24 Aug 2010 08:15:19 +1000
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <AANLkTiniWduAnWfmw+rV06fWAUYGNj4USce_cTOsoBgW@mail.gmail.com>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
	<2C284C09-3819-4858-A75A-34597DD668B7@gmail.com>
	<AANLkTimFeoZsRdUfWfhSyievK_819KFRoqDO2H3sc2JN@mail.gmail.com>
	<4C72D552.2030306@voidspace.org.uk>
	<AANLkTinzZ40ykb+JHFFJ9W=4ww5AwiLnd=_s5pVgqVaN@mail.gmail.com>
	<65FC8A3B-F9AF-4ED9-B63C-41335EF49E1A@gmail.com>
	<AANLkTiniuGQpt6dS4wi1yUBcBP2GZPDdStzL39T-kkFt@mail.gmail.com>
	<4C72E1F2.2020209@voidspace.org.uk>
	<AANLkTimGMunx9uEJMqDrQYLjKAOmypWQoOuACLDpWkGQ@mail.gmail.com>
	<4C72E372.5060201@voidspace.org.uk>
	<AANLkTiniWduAnWfmw+rV06fWAUYGNj4USce_cTOsoBgW@mail.gmail.com>
Message-ID: <AANLkTikSKdYRu5kJDxLT-m4Y_bM33mY+kWaBawyreTRo@mail.gmail.com>

On Tue, Aug 24, 2010 at 7:40 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> Properties are allowed to do whatever the heck they want. That doesn't mean
>> that you have to execute code to determine whether they exist or not.
>
> If you don't want to execute properties, do the lookup on the type,
> not the instance (obviously, you know the dance you need to do, since
> you've linked the code where you did it). Having apparently simple
> query operations like hasattr/getattr/len/etc execute arbitrary code
> is where much of the language's flexibility comes from, so I don't see
> how it can really be surprising when it happens.

Now, it may be worth considering an addition to the inspect module
that was basically:

def getattr_static(obj, attr):
    """Retrieve attributes without triggering dynamic lookup via the
descriptor protocol,
        __getattr__ or __getattribute__.

        Note: this function may not be able to retrieve all attributes
reported by dir(obj)
    """
    try:
        instance_dict = object.__getattribute__(obj, "__dict__")
    except AttributeError:
        pass
    else:
        if attr in instance_dict:
            return instance_dict[attr]
    for entry in getmro(obj.__class__):
        try:
            return entry.__dict__[attr]
        except AttributeError:
            pass

(not needing to deal with classic classes simplifies things a bit)

So, allowing for the fact that dir() may report attributes that can
only be found via dynamic lookup, your get_docstrings example could
become something like:

def get_docstrings(obj):
    try:
        members = dir(obj)
    except Exception:
        members = []
    for member in members:
        try:
            doc = getattr_static(obj, member).__doc__
        except AttributeError:
            doc = None
        yield member, doc

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From ncoghlan at gmail.com  Tue Aug 24 00:17:20 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 24 Aug 2010 08:17:20 +1000
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <4C72ECDC.8080104@voidspace.org.uk>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
	<2C284C09-3819-4858-A75A-34597DD668B7@gmail.com>
	<AANLkTimFeoZsRdUfWfhSyievK_819KFRoqDO2H3sc2JN@mail.gmail.com>
	<4C72D552.2030306@voidspace.org.uk>
	<AANLkTinzZ40ykb+JHFFJ9W=4ww5AwiLnd=_s5pVgqVaN@mail.gmail.com>
	<65FC8A3B-F9AF-4ED9-B63C-41335EF49E1A@gmail.com>
	<AANLkTiniuGQpt6dS4wi1yUBcBP2GZPDdStzL39T-kkFt@mail.gmail.com>
	<4C72E1F2.2020209@voidspace.org.uk>
	<AANLkTimGMunx9uEJMqDrQYLjKAOmypWQoOuACLDpWkGQ@mail.gmail.com>
	<4C72E372.5060201@voidspace.org.uk>
	<AANLkTiniWduAnWfmw+rV06fWAUYGNj4USce_cTOsoBgW@mail.gmail.com>
	<4C72ECDC.8080104@voidspace.org.uk>
Message-ID: <AANLkTim9Po1Db199MJ8h4tvoazpBN9rtGjZB4qC4JNmi@mail.gmail.com>

On Tue, Aug 24, 2010 at 7:49 AM, Michael Foord
<fuzzyman at voidspace.org.uk> wrote:
> Certainly that is true for len. getattr obviously involves invoking code if
> you are fetching a property or descriptor. No idea how you conclude that
> hasattr executing code adds flexibility to the language though.

Proxy objects like the one in the weakref module don't work if
hasattr() doesn't implicitly invoke __getattr__.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From greg.ewing at canterbury.ac.nz  Tue Aug 24 01:16:17 2010
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Tue, 24 Aug 2010 11:16:17 +1200
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <4C72D26B.3060705@voidspace.org.uk>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
	<2C284C09-3819-4858-A75A-34597DD668B7@gmail.com>
	<4C72D26B.3060705@voidspace.org.uk>
Message-ID: <4C730141.9080409@canterbury.ac.nz>

Michael Foord wrote:

> It would be backwards incompatible with usage of hasattr for dynamically 
> created 'members' using __getattr__ though.

Also keep in mind that builtin types mostly don't keep
their attributes in dictionaries. To make this work
properly, hasattr would need its own special method.

-- 
Greg

From steve at pearwood.info  Tue Aug 24 01:56:27 2010
From: steve at pearwood.info (Steven D'Aprano)
Date: Tue, 24 Aug 2010 09:56:27 +1000
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <AANLkTikM4GZNn8Yc9c=4FkRm=ewa1DUmFff+tPw_PWsL@mail.gmail.com>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
	<46A37D14-D024-4CF8-9BED-E87B69734B8C@gmail.com>
	<AANLkTikM4GZNn8Yc9c=4FkRm=ewa1DUmFff+tPw_PWsL@mail.gmail.com>
Message-ID: <201008240956.27584.steve@pearwood.info>

On Tue, 24 Aug 2010 06:50:19 am Guido van Rossum wrote:

> > * Is there anything that hasattr(obj, key) can or should do that
> >   can't already be done with getattr(obj, key, None)?
> >   If not, do we really need to change anything?
>
> getattr(obj, 'key', None) returns None when obj.key exists and has
> the value None. The workaround is ugly.

Why do you say it's ugly? It's a short, sweet, simple two-liner:

mark = object()
getattr(obj, 'key', mark) is not mark

Nothing ugly about it at all. But if somebody really objected to using a 
two lines, they could put it in a utility function.

It still doesn't cope with dynamically-generated attributes that are 
either expensive or have side-effects (both of which are probably poor 
design, but nevertheless I'm sure they're out there), but neither does 
the existing hasattr.


> * Why do people typically use hasattr() instead getattr()?
>
> >    Aren't they are really trying to just determine
> >    whether a key exists somewhere in the MRO?
> >    If so, then doing anything more than that is probably a
> > surprise.
>
> Most users who call hasattr() probably don't even know what MRO
> means. 

Well, yes, but most users never write __getattr__ or __getattribute__ 
methods either.

I have always thought that hasattr() does what it says on the box: it 
tests for the *existence* of an attribute, that is, one that statically 
exists rather than being dynamically generated. In other words, it is a 
key in the instance __dict__ or is inherited from the class __dict__ or 
that of a superclass, or a __slot__.

Now that I know that hasattr doesn't do what I thought it does or what 
the name implies it does, it has little or no utility for me. In the 
future, I'll just write a try...except block and catch errors if the 
attribute doesn't exist.



-- 
Steven D'Aprano

From benjamin at python.org  Tue Aug 24 02:04:16 2010
From: benjamin at python.org (Benjamin Peterson)
Date: Mon, 23 Aug 2010 19:04:16 -0500
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <201008240956.27584.steve@pearwood.info>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
	<46A37D14-D024-4CF8-9BED-E87B69734B8C@gmail.com>
	<AANLkTikM4GZNn8Yc9c=4FkRm=ewa1DUmFff+tPw_PWsL@mail.gmail.com>
	<201008240956.27584.steve@pearwood.info>
Message-ID: <AANLkTikKKAjFqyTFTWCgYoJDST5jaSDz_SKjRJhdGnNp@mail.gmail.com>

2010/8/23 Steven D'Aprano <steve at pearwood.info>:
> On Tue, 24 Aug 2010 06:50:19 am Guido van Rossum wrote:
>
>> > * Is there anything that hasattr(obj, key) can or should do that
>> > ? can't already be done with getattr(obj, key, None)?
>> > ? If not, do we really need to change anything?
>>
>> getattr(obj, 'key', None) returns None when obj.key exists and has
>> the value None. The workaround is ugly.
>
> Why do you say it's ugly? It's a short, sweet, simple two-liner:
>
> mark = object()
> getattr(obj, 'key', mark) is not mark
>
> Nothing ugly about it at all. But if somebody really objected to using a
> two lines, they could put it in a utility function.

That's not all, though. You still have to test it with an "if" and
that gets cumbersome after a while.

>
> I have always thought that hasattr() does what it says on the box: it
> tests for the *existence* of an attribute, that is, one that statically
> exists rather than being dynamically generated. In other words, it is a
> key in the instance __dict__ or is inherited from the class __dict__ or
> that of a superclass, or a __slot__.
>
> Now that I know that hasattr doesn't do what I thought it does or what
> the name implies it does, it has little or no utility for me. In the
> future, I'll just write a try...except block and catch errors if the
> attribute doesn't exist.

Well, that's exactly what hasattr does...



-- 
Regards,
Benjamin

From brett at python.org  Tue Aug 24 02:21:50 2010
From: brett at python.org (Brett Cannon)
Date: Mon, 23 Aug 2010 17:21:50 -0700
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <AANLkTikKKAjFqyTFTWCgYoJDST5jaSDz_SKjRJhdGnNp@mail.gmail.com>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
	<46A37D14-D024-4CF8-9BED-E87B69734B8C@gmail.com>
	<AANLkTikM4GZNn8Yc9c=4FkRm=ewa1DUmFff+tPw_PWsL@mail.gmail.com>
	<201008240956.27584.steve@pearwood.info>
	<AANLkTikKKAjFqyTFTWCgYoJDST5jaSDz_SKjRJhdGnNp@mail.gmail.com>
Message-ID: <AANLkTimghMVvRw0M4wsJfJCaxw0jEGaRV45DWyP+dVSX@mail.gmail.com>

On Mon, Aug 23, 2010 at 17:04, Benjamin Peterson <benjamin at python.org> wrote:
> 2010/8/23 Steven D'Aprano <steve at pearwood.info>:
>> On Tue, 24 Aug 2010 06:50:19 am Guido van Rossum wrote:
>>
>>> > * Is there anything that hasattr(obj, key) can or should do that
>>> > ? can't already be done with getattr(obj, key, None)?
>>> > ? If not, do we really need to change anything?
>>>
>>> getattr(obj, 'key', None) returns None when obj.key exists and has
>>> the value None. The workaround is ugly.
>>
>> Why do you say it's ugly? It's a short, sweet, simple two-liner:
>>
>> mark = object()
>> getattr(obj, 'key', mark) is not mark
>>
>> Nothing ugly about it at all. But if somebody really objected to using a
>> two lines, they could put it in a utility function.
>
> That's not all, though. You still have to test it with an "if" and
> that gets cumbersome after a while.

It is also non-obvious to any beginner. Are we really going to want to
propagate the knowledge of this trick as a fundamental idiom? I would
rather leave hasattr in that instance. But I'm +1 on only swallowing
AttributeError.

-Brett

>
>>
>> I have always thought that hasattr() does what it says on the box: it
>> tests for the *existence* of an attribute, that is, one that statically
>> exists rather than being dynamically generated. In other words, it is a
>> key in the instance __dict__ or is inherited from the class __dict__ or
>> that of a superclass, or a __slot__.
>>
>> Now that I know that hasattr doesn't do what I thought it does or what
>> the name implies it does, it has little or no utility for me. In the
>> future, I'll just write a try...except block and catch errors if the
>> attribute doesn't exist.
>
> Well, that's exactly what hasattr does...
>
>
>
> --
> Regards,
> Benjamin
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/brett%40python.org
>

From guido at python.org  Tue Aug 24 03:09:10 2010
From: guido at python.org (Guido van Rossum)
Date: Mon, 23 Aug 2010 18:09:10 -0700
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <201008240956.27584.steve@pearwood.info>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
	<46A37D14-D024-4CF8-9BED-E87B69734B8C@gmail.com>
	<AANLkTikM4GZNn8Yc9c=4FkRm=ewa1DUmFff+tPw_PWsL@mail.gmail.com>
	<201008240956.27584.steve@pearwood.info>
Message-ID: <AANLkTi=qHnY3ugXKurzO1hhCBOCjXBEpqd+O8TW93VT+@mail.gmail.com>

On Mon, Aug 23, 2010 at 4:56 PM, Steven D'Aprano <steve at pearwood.info> wrote:
> On Tue, 24 Aug 2010 06:50:19 am Guido van Rossum wrote:
>
>> > * Is there anything that hasattr(obj, key) can or should do that
>> > ? can't already be done with getattr(obj, key, None)?
>> > ? If not, do we really need to change anything?
>>
>> getattr(obj, 'key', None) returns None when obj.key exists and has
>> the value None. The workaround is ugly.
>
> Why do you say it's ugly? It's a short, sweet, simple two-liner:
>
> mark = object()
> getattr(obj, 'key', mark) is not mark
>
> Nothing ugly about it at all. But if somebody really objected to using a
> two lines, they could put it in a utility function.

Because if you didn't have the foresight to write that utility
function, you have to break your train of thought (aka yak shaving) to
either write it (big yak) or write those two lines (little yak, times
the number of times it happens). Whereas with hasattr() you can just
type the correct hasattr() expression in-line in the if that you
already started typing.

> It still doesn't cope with dynamically-generated attributes that are
> either expensive or have side-effects (both of which are probably poor
> design, but nevertheless I'm sure they're out there), but neither does
> the existing hasattr.
>
>
>> * Why do people typically use hasattr() instead getattr()?
>>
>> > ? ?Aren't they are really trying to just determine
>> > ? ?whether a key exists somewhere in the MRO?
>> > ? ?If so, then doing anything more than that is probably a
>> > surprise.
>>
>> Most users who call hasattr() probably don't even know what MRO
>> means.
>
> Well, yes, but most users never write __getattr__ or __getattribute__
> methods either.
>
> I have always thought that hasattr() does what it says on the box: it
> tests for the *existence* of an attribute, that is, one that statically
> exists rather than being dynamically generated. In other words, it is a
> key in the instance __dict__ or is inherited from the class __dict__ or
> that of a superclass, or a __slot__.

It tests for the existence of an attribute -- how the attribute is
defined should not have to occur to you (and there are lots of other
ways for attributes to be defined besides the ways you came up with
just now).

> Now that I know that hasattr doesn't do what I thought it does or what
> the name implies it does, it has little or no utility for me. In the
> future, I'll just write a try...except block and catch errors if the
> attribute doesn't exist.

The try/except block *also* requires you to break your train of
thought. And most of the time the error case just isn't important. You
sound like you are over-engineering it and focusing too  much on
performance instead of on getting things done. Like those people who
learn that it saves an usec to copy a built-in function into a defalt
arg (def foo(arg1, len=len):  ...) and then overuse the trick even
when the time it took them to write the exra line is more than the
time they'll save in a lifetime in execution time.

-- 
--Guido van Rossum (python.org/~guido)

From yselivanov at gmail.com  Tue Aug 24 04:14:07 2010
From: yselivanov at gmail.com (Yury Selivanov)
Date: Mon, 23 Aug 2010 22:14:07 -0400
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <AANLkTi=9E3_Bo1X9_gPxaK5dUrA=whmZbBdHY+Qknt_S@mail.gmail.com>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
	<AANLkTimo2u2xGm3DjT7KU4uHM+_0JuwdjsQtCSYow15z@mail.gmail.com>
	<AANLkTi=9E3_Bo1X9_gPxaK5dUrA=whmZbBdHY+Qknt_S@mail.gmail.com>
Message-ID: <32BD800F-A847-4A98-90B6-26FCC1681480@gmail.com>

> On 2010-08-23, at 10:56 AM, Guido van Rossum wrote:
> On Mon, Aug 23, 2010 at 7:46 AM, Benjamin Peterson <benjamin at python.org> wrote:
>> 2010/8/23 Yury Selivanov <yselivanov at gmail.com>:
>>> 1) I propose to change 'hasattr' behaviour in Python 3, making it to swallow only AttributeError exceptions (exactly like 'getattr').  Probably, Python 3.2 release is our last chance.
>> 
>> I would be in support of that.
> 
> I am cautiously in favor. The existing behavior is definitely a
> mistake and a trap. But it has been depended on for almost 20 years
> now.
> 
> I recommend that you create a patch, apply it, run the *entire* stdlib
> test suite and see how much breaks. That will give you an idea of the
> damage to expect for 3rd party code.

Have done a little testing.

The patch to builtin 'hasattr' function is trivial, and can be found 
attached to this letter (with the corresponding unittest):

-        if (!PyErr_ExceptionMatches(PyExc_Exception))
+        if (!PyErr_ExceptionMatches(PyExc_AttributeError))

So, after applying it, hasattr swallows only AttributeError exceptions.


All tests from Python 3.2 test suite were good.

After that, I've applied the patch on Python 2.6 and tested SqlAlchemy,
Django and Twisted.

- SqlAlchemy has failed three unittests, but those tests were designed
specifically to handle 'hasattr' weird behaviour, so we can consider
the change has no impact on SqlAlchemy.

- Twisted - failed 3 tests out of ~3200, but it fails them on the same
machine on an unpatched Python too, and they seem unrelated.

- Django - all tests passed.


I tested our internal company framework (~100K LOC) and, again, all
tests passed.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: hasattr.patch
Type: application/octet-stream
Size: 2007 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100823/ab38878d/attachment.obj>

From guido at python.org  Tue Aug 24 04:37:03 2010
From: guido at python.org (Guido van Rossum)
Date: Mon, 23 Aug 2010 19:37:03 -0700
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <32BD800F-A847-4A98-90B6-26FCC1681480@gmail.com>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
	<AANLkTimo2u2xGm3DjT7KU4uHM+_0JuwdjsQtCSYow15z@mail.gmail.com>
	<AANLkTi=9E3_Bo1X9_gPxaK5dUrA=whmZbBdHY+Qknt_S@mail.gmail.com>
	<32BD800F-A847-4A98-90B6-26FCC1681480@gmail.com>
Message-ID: <AANLkTinFXKMZrbnry7U94dHEckxoL4m7zhr8t0+KjA6y@mail.gmail.com>

Yuri, I think you are making a good case (though I would like for you
to be a good citizen and use the bug tracker to submit this for
review). Benjamin, what do you think?

--Guido

On Mon, Aug 23, 2010 at 7:14 PM, Yury Selivanov <yselivanov at gmail.com> wrote:
>> On 2010-08-23, at 10:56 AM, Guido van Rossum wrote:
>> On Mon, Aug 23, 2010 at 7:46 AM, Benjamin Peterson <benjamin at python.org> wrote:
>>> 2010/8/23 Yury Selivanov <yselivanov at gmail.com>:
>>>> 1) I propose to change 'hasattr' behaviour in Python 3, making it to swallow only AttributeError exceptions (exactly like 'getattr'). ?Probably, Python 3.2 release is our last chance.
>>>
>>> I would be in support of that.
>>
>> I am cautiously in favor. The existing behavior is definitely a
>> mistake and a trap. But it has been depended on for almost 20 years
>> now.
>>
>> I recommend that you create a patch, apply it, run the *entire* stdlib
>> test suite and see how much breaks. That will give you an idea of the
>> damage to expect for 3rd party code.
>
> Have done a little testing.
>
> The patch to builtin 'hasattr' function is trivial, and can be found
> attached to this letter (with the corresponding unittest):
>
> - ? ? ? ?if (!PyErr_ExceptionMatches(PyExc_Exception))
> + ? ? ? ?if (!PyErr_ExceptionMatches(PyExc_AttributeError))
>
> So, after applying it, hasattr swallows only AttributeError exceptions.
>
>
> All tests from Python 3.2 test suite were good.
>
> After that, I've applied the patch on Python 2.6 and tested SqlAlchemy,
> Django and Twisted.
>
> - SqlAlchemy has failed three unittests, but those tests were designed
> specifically to handle 'hasattr' weird behaviour, so we can consider
> the change has no impact on SqlAlchemy.
>
> - Twisted - failed 3 tests out of ~3200, but it fails them on the same
> machine on an unpatched Python too, and they seem unrelated.
>
> - Django - all tests passed.
>
>
> I tested our internal company framework (~100K LOC) and, again, all
> tests passed.
>
>
>



-- 
--Guido van Rossum (python.org/~guido)

From yselivanov at gmail.com  Tue Aug 24 04:58:19 2010
From: yselivanov at gmail.com (Yury Selivanov)
Date: Mon, 23 Aug 2010 22:58:19 -0400
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <AANLkTinFXKMZrbnry7U94dHEckxoL4m7zhr8t0+KjA6y@mail.gmail.com>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
	<AANLkTimo2u2xGm3DjT7KU4uHM+_0JuwdjsQtCSYow15z@mail.gmail.com>
	<AANLkTi=9E3_Bo1X9_gPxaK5dUrA=whmZbBdHY+Qknt_S@mail.gmail.com>
	<32BD800F-A847-4A98-90B6-26FCC1681480@gmail.com>
	<AANLkTinFXKMZrbnry7U94dHEckxoL4m7zhr8t0+KjA6y@mail.gmail.com>
Message-ID: <10CF0468-6D0B-4AAA-8DD0-B179ECEF5436@gmail.com>

> On 2010-08-23, at 10:37 PM, Guido van Rossum wrote:
> Yuri, I think you are making a good case (though I would like for you
> to be a good citizen and use the bug tracker to submit this for
> review). Benjamin, what do you think?

NP, issue #9666 ;-)

-
Yury

From benjamin at python.org  Tue Aug 24 05:18:51 2010
From: benjamin at python.org (Benjamin Peterson)
Date: Mon, 23 Aug 2010 22:18:51 -0500
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <AANLkTinFXKMZrbnry7U94dHEckxoL4m7zhr8t0+KjA6y@mail.gmail.com>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
	<AANLkTimo2u2xGm3DjT7KU4uHM+_0JuwdjsQtCSYow15z@mail.gmail.com>
	<AANLkTi=9E3_Bo1X9_gPxaK5dUrA=whmZbBdHY+Qknt_S@mail.gmail.com>
	<32BD800F-A847-4A98-90B6-26FCC1681480@gmail.com>
	<AANLkTinFXKMZrbnry7U94dHEckxoL4m7zhr8t0+KjA6y@mail.gmail.com>
Message-ID: <AANLkTin8OyZgHchqimiV0x7-02eJf=1MDYi4o-q=FNou@mail.gmail.com>

2010/8/23 Guido van Rossum <guido at python.org>:
> Yuri, I think you are making a good case (though I would like for you
> to be a good citizen and use the bug tracker to submit this for
> review). Benjamin, what do you think?

I will have a look right now.



-- 
Regards,
Benjamin

From fuzzyman at voidspace.org.uk  Tue Aug 24 09:40:05 2010
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Tue, 24 Aug 2010 10:40:05 +0300
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <AANLkTik8Ld2z-QsiT0=c0zWwUNyw_pAQkROMpUGJXHth@mail.gmail.com>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>	<2C284C09-3819-4858-A75A-34597DD668B7@gmail.com>	<AANLkTimFeoZsRdUfWfhSyievK_819KFRoqDO2H3sc2JN@mail.gmail.com>	<4C72D552.2030306@voidspace.org.uk>	<AANLkTinzZ40ykb+JHFFJ9W=4ww5AwiLnd=_s5pVgqVaN@mail.gmail.com>	<65FC8A3B-F9AF-4ED9-B63C-41335EF49E1A@gmail.com>	<AANLkTiniuGQpt6dS4wi1yUBcBP2GZPDdStzL39T-kkFt@mail.gmail.com>	<4C72E1F2.2020209@voidspace.org.uk>	<AANLkTimGMunx9uEJMqDrQYLjKAOmypWQoOuACLDpWkGQ@mail.gmail.com>	<4C72E372.5060201@voidspace.org.uk>	<AANLkTiniWduAnWfmw+rV06fWAUYGNj4USce_cTOsoBgW@mail.gmail.com>	<AANLkTikSKdYRu5kJDxLT-m4Y_bM33mY+kWaBawyreTRo@mail.gmail.com>
	<AANLkTik8Ld2z-QsiT0=c0zWwUNyw_pAQkROMpUGJXHth@mail.gmail.com>
Message-ID: <4C737755.30509@voidspace.org.uk>

  On 24/08/2010 01:25, Nick Coghlan wrote:
> On Tue, Aug 24, 2010 at 8:15 AM, Nick Coghlan<ncoghlan at gmail.com>  wrote:
>> Now, it may be worth considering an addition to the inspect module
>> that was basically:
>>
>> def getattr_static(obj, attr):
>>     """Retrieve attributes without triggering dynamic lookup via the
>> descriptor protocol,
>>         __getattr__ or __getattribute__.
>>
>>         Note: this function may not be able to retrieve all attributes
>> reported by dir(obj)
>>     """
>>     try:
>>         instance_dict = object.__getattribute__(obj, "__dict__")
>>     except AttributeError:
>>         pass
>>     else:
>>         if attr in instance_dict:
>>             return instance_dict[attr]
>>     for entry in getmro(obj.__class__):
>>         try:
>>             return entry.__dict__[attr]
>>         except AttributeError:
>>             pass
> Second attempt with a default value parameter and correctly raising
> AttributeError if not found:
>
> _sentinel = object()
> def getattr_static(obj, attr, default=_sentinel):
>      """Retrieve attributes without triggering dynamic lookup via the
>          descriptor protocol,  __getattr__ or __getattribute__.
>
>          Note: this function may not be able to retrieve all attributes
>          reported by dir(obj)
>      """
>      try:
>          instance_dict = object.__getattribute__(obj, "__dict__")
>      except AttributeError:
>          pass
>      else:
>          if attr in instance_dict:
>              return instance_dict[attr]
>      for entry in getmro(obj.__class__):
>          try:
>              return entry.__dict__[attr]
>          except AttributeError:
>              pass
>      if default is not _sentinel:
>          return default
>      raise AttributeError(attr)
>

This doesn't correctly handle the case where obj is a type object or obj 
uses __slots__.

If I have time (currently on vacation with only intermittent internet 
access) I'll provide an update.

Michael


> Cheers,
> Nick.
>


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


From hrvoje.niksic at avl.com  Tue Aug 24 13:12:45 2010
From: hrvoje.niksic at avl.com (Hrvoje Niksic)
Date: Tue, 24 Aug 2010 13:12:45 +0200
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <AANLkTi=9E3_Bo1X9_gPxaK5dUrA=whmZbBdHY+Qknt_S@mail.gmail.com>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>	<AANLkTimo2u2xGm3DjT7KU4uHM+_0JuwdjsQtCSYow15z@mail.gmail.com>
	<AANLkTi=9E3_Bo1X9_gPxaK5dUrA=whmZbBdHY+Qknt_S@mail.gmail.com>
Message-ID: <4C73A92D.4050503@avl.com>

On 08/23/2010 04:56 PM, Guido van Rossum wrote:
> On Mon, Aug 23, 2010 at 7:46 AM, Benjamin Peterson<benjamin at python.org>  wrote:
>>  2010/8/23 Yury Selivanov<yselivanov at gmail.com>:
>>>  1) I propose to change 'hasattr' behaviour in Python 3, making it to swallow only AttributeError exceptions (exactly like 'getattr').  Probably, Python 3.2 release is our last chance.
>>
>>  I would be in support of that.
>
> I am cautiously in favor. The existing behavior is definitely a
> mistake and a trap. But it has been depended on for almost 20 years
> now.

I'll note that a similar incompatible change has made it to python2.6. 
This has bitten us in production:

class X(object):
     def __getattr__(self, name):
         raise KeyError, "error looking for %s" % (name,)

     def __iter__(self):
         yield 1

print list(X())

I would expect it to print [1], and in python2.5 it does.  In python2.6 
it raises a KeyError!  The attribute being looked up is an unexpected one:

{hrzagude5003}[~]$ python2.6 a.py
Traceback (most recent call last):
   File "a.py", line 8, in <module>
     print list(X())
   File "a.py", line 3, in __getattr__
     raise KeyError, "error looking for %s" % (name,)
KeyError: 'error looking for __length_hint__'

The __length_hint__ lookup expects either no exception or 
AttributeError, and will propagate others.  I'm not sure if this is a 
bug.  On the one hand, throwing anything except AttributeError from 
__getattr__ is bad style (which is why we fixed the bug by deriving our 
business exception from AttributeError), but the __length_hint__ check 
is supposed to be an internal optimization completely invisible to the 
caller of list().

Being aware that this can be construed as an argument both in favor and 
against the change at hand, my point is that, if propagating 
non-AttributeError exceptions is done in checks intended to be 
invisible, it should certainly be done in hasattr, where it is at least 
obvious what is being done.  Other generic functions and operators, 
including boolean ones such as ==, happily propagate exceptions.

Also, don't expect that this won't break code out there.  It certainly 
will, it's only a matter of assessment whether such code was broken in a 
different, harder to detect way, to begin with.

From steve at pearwood.info  Tue Aug 24 13:51:21 2010
From: steve at pearwood.info (Steven D'Aprano)
Date: Tue, 24 Aug 2010 21:51:21 +1000
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <AANLkTi=qHnY3ugXKurzO1hhCBOCjXBEpqd+O8TW93VT+@mail.gmail.com>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
	<201008240956.27584.steve@pearwood.info>
	<AANLkTi=qHnY3ugXKurzO1hhCBOCjXBEpqd+O8TW93VT+@mail.gmail.com>
Message-ID: <201008242151.21940.steve@pearwood.info>

On Tue, 24 Aug 2010 11:09:10 am Guido van Rossum wrote:
> On Mon, Aug 23, 2010 at 4:56 PM, Steven D'Aprano <steve at pearwood.info> 
wrote:
[...]
> > I have always thought that hasattr() does what it says on the box:
> > it tests for the *existence* of an attribute, that is, one that
> > statically exists rather than being dynamically generated. In other
> > words, it is a key in the instance __dict__ or is inherited from
> > the class __dict__ or that of a superclass, or a __slot__.
>
> It tests for the existence of an attribute -- how the attribute is
> defined should not have to occur to you 

But that's the thing... as far as I am concerned, a dynamically defined 
attribute *doesn't* exist. If it existed, __getattr__ would never be 
called. A minor semantic difference, to be sure, but it's real to me.

Whether I should care about the difference is a separate issue.

This conversation has been valuable to me for one thing though... it 
reminded me of a piece of code I had written a long time ago. A 
simplified version:

class K(object):
    def __getattribute__(self, name):
        if hasattr(self, name):
            # no computation needed
            print "Attr exists"
        else:
            # compute something...
            print "Attr doesn't exist"

I couldn't work out why it was behaving so strangely, and rather than 
spend time investigating, I abandoned the whole dynamic attribute 
approach and did something completely different. So at least now I know 
why it wasn't working as I expected.


> (and there are lots of other 
> ways for attributes to be defined besides the ways you came up with
> just now).

I never suggested that it would be easy.


> > Now that I know that hasattr doesn't do what I thought it does or
> > what the name implies it does, it has little or no utility for me.
> > In the future, I'll just write a try...except block and catch
> > errors if the attribute doesn't exist.
>
> The try/except block *also* requires you to break your train of
> thought. And most of the time the error case just isn't important.
> You sound like you are over-engineering it and focusing too  much on
> performance instead of on getting things done.

Performance could be an issue, of course, if somebody writes an 
expensive __getattr__ or property. Computed attributes should be cheap. 
But I'm actually more concerned about side-effects than performance. If 
I'm not worried about potential side-effects, I use a try...except 
block. If I am worried, I "Look Before You Leap". Only now I've learned 
that what I thought was LBYL is nothing of the sort, and hasattr gives 
me no protection against side-effects. That being the case, I might as 
well just stick to try...except and be done with it.

I'm not suggesting this is the One True Way. If others prefer hasattr, 
then I have no problem with that. I'm just saying that now that I know 
what it actually does, its value *for me* is minimal.


> Like those people who 
> learn that it saves an usec to copy a built-in function into a defalt
> arg (def foo(arg1, len=len):  ...) and then overuse the trick even
> when the time it took them to write the exra line is more than the
> time they'll save in a lifetime in execution time.

Aha! The penny drops! Is that why so many methods in random.Random have 
an "int=int" argument? E.g.

    def randrange(self, start, stop=None, step=1, int=int, default=None,
                  maxwidth=1L<<BPF):

I'd wondered about that.

So there you go, now I've learned two things.



-- 
Steven D'Aprano

From benjamin at python.org  Tue Aug 24 14:31:18 2010
From: benjamin at python.org (Benjamin Peterson)
Date: Tue, 24 Aug 2010 07:31:18 -0500
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <4C73A92D.4050503@avl.com>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
	<AANLkTimo2u2xGm3DjT7KU4uHM+_0JuwdjsQtCSYow15z@mail.gmail.com>
	<AANLkTi=9E3_Bo1X9_gPxaK5dUrA=whmZbBdHY+Qknt_S@mail.gmail.com>
	<4C73A92D.4050503@avl.com>
Message-ID: <AANLkTik+q=smAPGhd3yHFBtk5G4TrtzvqdFnQFN5cvpB@mail.gmail.com>

2010/8/24 Hrvoje Niksic <hrvoje.niksic at avl.com>:
> The __length_hint__ lookup expects either no exception or AttributeError,
> and will propagate others. ?I'm not sure if this is a bug. ?On the one hand,
> throwing anything except AttributeError from __getattr__ is bad style (which
> is why we fixed the bug by deriving our business exception from
> AttributeError), but the __length_hint__ check is supposed to be an internal
> optimization completely invisible to the caller of list().

__length_hint__ is internal and undocumented, so it can do whatever it wants.



-- 
Regards,
Benjamin

From hrvoje.niksic at avl.com  Tue Aug 24 15:37:16 2010
From: hrvoje.niksic at avl.com (Hrvoje Niksic)
Date: Tue, 24 Aug 2010 15:37:16 +0200
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <AANLkTik+q=smAPGhd3yHFBtk5G4TrtzvqdFnQFN5cvpB@mail.gmail.com>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>	<AANLkTimo2u2xGm3DjT7KU4uHM+_0JuwdjsQtCSYow15z@mail.gmail.com>	<AANLkTi=9E3_Bo1X9_gPxaK5dUrA=whmZbBdHY+Qknt_S@mail.gmail.com>	<4C73A92D.4050503@avl.com>
	<AANLkTik+q=smAPGhd3yHFBtk5G4TrtzvqdFnQFN5cvpB@mail.gmail.com>
Message-ID: <4C73CB0C.3060600@avl.com>

On 08/24/2010 02:31 PM, Benjamin Peterson wrote:
> 2010/8/24 Hrvoje Niksic<hrvoje.niksic at avl.com>:
>>  The __length_hint__ lookup expects either no exception or AttributeError,
>>  and will propagate others.  I'm not sure if this is a bug.  On the one hand,
>>  throwing anything except AttributeError from __getattr__ is bad style (which
>>  is why we fixed the bug by deriving our business exception from
>>  AttributeError), but the __length_hint__ check is supposed to be an internal
>>  optimization completely invisible to the caller of list().
>
> __length_hint__ is internal and undocumented, so it can do whatever it wants.

Of course, but that's beside the point.  In this case __length_hint__ 
was neither implemented in the class, nor were we aware of its 
existence, and the code still broke (as in the example in previous 
mail).  The point I'm making is that:

a) a "business" case of throwing anything other than AttributeError from 
__getattr__ and friends is almost certainly a bug waiting to happen, and

b) making the proposed change is bound to break real, production code.

I still agree with the proposed change, but I wanted to also point out 
that it will cause breakage and illustrate it with a similar real-world 
example that occurred during migration to python 2.6.

From benjamin at python.org  Tue Aug 24 15:45:19 2010
From: benjamin at python.org (Benjamin Peterson)
Date: Tue, 24 Aug 2010 08:45:19 -0500
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <4C73CB0C.3060600@avl.com>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
	<AANLkTimo2u2xGm3DjT7KU4uHM+_0JuwdjsQtCSYow15z@mail.gmail.com>
	<AANLkTi=9E3_Bo1X9_gPxaK5dUrA=whmZbBdHY+Qknt_S@mail.gmail.com>
	<4C73A92D.4050503@avl.com>
	<AANLkTik+q=smAPGhd3yHFBtk5G4TrtzvqdFnQFN5cvpB@mail.gmail.com>
	<4C73CB0C.3060600@avl.com>
Message-ID: <AANLkTik-uikSKVy9PEoZTJS+k4r5Fn1KMjv0qiZ0ALYD@mail.gmail.com>

2010/8/24 Hrvoje Niksic <hrvoje.niksic at avl.com>:
> On 08/24/2010 02:31 PM, Benjamin Peterson wrote:
>>
>> 2010/8/24 Hrvoje Niksic<hrvoje.niksic at avl.com>:
>>>
>>> ?The __length_hint__ lookup expects either no exception or
>>> AttributeError,
>>> ?and will propagate others. ?I'm not sure if this is a bug. ?On the one
>>> hand,
>>> ?throwing anything except AttributeError from __getattr__ is bad style
>>> (which
>>> ?is why we fixed the bug by deriving our business exception from
>>> ?AttributeError), but the __length_hint__ check is supposed to be an
>>> internal
>>> ?optimization completely invisible to the caller of list().
>>
>> __length_hint__ is internal and undocumented, so it can do whatever it
>> wants.
>
> Of course, but that's beside the point. ?In this case __length_hint__ was
> neither implemented in the class, nor were we aware of its existence, and
> the code still broke (as in the example in previous mail). ?The point I'm
> making is that:
>
> a) a "business" case of throwing anything other than AttributeError from
> __getattr__ and friends is almost certainly a bug waiting to happen, and
>
> b) making the proposed change is bound to break real, production code.

I agree with. This is why the change is not making its way into any
maintenance release.



-- 
Regards,
Benjamin

From pje at telecommunity.com  Tue Aug 24 16:22:06 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Tue, 24 Aug 2010 10:22:06 -0400
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <4C73CB0C.3060600@avl.com>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
	<AANLkTimo2u2xGm3DjT7KU4uHM+_0JuwdjsQtCSYow15z@mail.gmail.com>
	<AANLkTi=9E3_Bo1X9_gPxaK5dUrA=whmZbBdHY+Qknt_S@mail.gmail.com>
	<4C73A92D.4050503@avl.com>
	<AANLkTik+q=smAPGhd3yHFBtk5G4TrtzvqdFnQFN5cvpB@mail.gmail.com>
	<4C73CB0C.3060600@avl.com>
Message-ID: <20100824142212.494343A40A5@sparrow.telecommunity.com>

At 03:37 PM 8/24/2010 +0200, Hrvoje Niksic wrote:
>a) a "business" case of throwing anything other than AttributeError 
>from __getattr__ and friends is almost certainly a bug waiting to happen, and

FYI, best practice for __getattr__ is generally to bail with an 
AttributeError as soon as you see double underscores in the name, 
unless you intend to support special attributes.

I don't think this is documented anywhere, but experience got this 
pretty ingrained in my head since Python 2.2 or even earlier.


From benjamin at python.org  Tue Aug 24 16:26:09 2010
From: benjamin at python.org (Benjamin Peterson)
Date: Tue, 24 Aug 2010 09:26:09 -0500
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <20100824142212.494343A40A5@sparrow.telecommunity.com>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
	<AANLkTimo2u2xGm3DjT7KU4uHM+_0JuwdjsQtCSYow15z@mail.gmail.com>
	<AANLkTi=9E3_Bo1X9_gPxaK5dUrA=whmZbBdHY+Qknt_S@mail.gmail.com>
	<4C73A92D.4050503@avl.com>
	<AANLkTik+q=smAPGhd3yHFBtk5G4TrtzvqdFnQFN5cvpB@mail.gmail.com>
	<4C73CB0C.3060600@avl.com>
	<20100824142212.494343A40A5@sparrow.telecommunity.com>
Message-ID: <AANLkTi=rkL8Kv3tkC=GxERsVDxVVzrRQJc_KWgOj0k+B@mail.gmail.com>

2010/8/24 P.J. Eby <pje at telecommunity.com>:
> At 03:37 PM 8/24/2010 +0200, Hrvoje Niksic wrote:
>>
>> a) a "business" case of throwing anything other than AttributeError from
>> __getattr__ and friends is almost certainly a bug waiting to happen, and
>
> FYI, best practice for __getattr__ is generally to bail with an
> AttributeError as soon as you see double underscores in the name, unless you
> intend to support special attributes.

Unless you're in an old-style class, you shouldn't get an double
underscore methods in __getattr__ (or __getattribute__). If you do,
it's a bug.


-- 
Regards,
Benjamin

From steve at holdenweb.com  Tue Aug 24 16:49:07 2010
From: steve at holdenweb.com (Steve Holden)
Date: Tue, 24 Aug 2010 10:49:07 -0400
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <AANLkTik-uikSKVy9PEoZTJS+k4r5Fn1KMjv0qiZ0ALYD@mail.gmail.com>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>	<AANLkTimo2u2xGm3DjT7KU4uHM+_0JuwdjsQtCSYow15z@mail.gmail.com>	<AANLkTi=9E3_Bo1X9_gPxaK5dUrA=whmZbBdHY+Qknt_S@mail.gmail.com>	<4C73A92D.4050503@avl.com>	<AANLkTik+q=smAPGhd3yHFBtk5G4TrtzvqdFnQFN5cvpB@mail.gmail.com>	<4C73CB0C.3060600@avl.com>
	<AANLkTik-uikSKVy9PEoZTJS+k4r5Fn1KMjv0qiZ0ALYD@mail.gmail.com>
Message-ID: <4C73DBE3.1020704@holdenweb.com>

On 8/24/2010 9:45 AM, Benjamin Peterson wrote:
> 2010/8/24 Hrvoje Niksic <hrvoje.niksic at avl.com>:
>> On 08/24/2010 02:31 PM, Benjamin Peterson wrote:
>>>
>>> 2010/8/24 Hrvoje Niksic<hrvoje.niksic at avl.com>:
>>>>
>>>>  The __length_hint__ lookup expects either no exception or
>>>> AttributeError,
>>>>  and will propagate others.  I'm not sure if this is a bug.  On the one
>>>> hand,
>>>>  throwing anything except AttributeError from __getattr__ is bad style
>>>> (which
>>>>  is why we fixed the bug by deriving our business exception from
>>>>  AttributeError), but the __length_hint__ check is supposed to be an
>>>> internal
>>>>  optimization completely invisible to the caller of list().
>>>
>>> __length_hint__ is internal and undocumented, so it can do whatever it
>>> wants.
>>
>> Of course, but that's beside the point.  In this case __length_hint__ was
>> neither implemented in the class, nor were we aware of its existence, and
>> the code still broke (as in the example in previous mail).  The point I'm
>> making is that:
>>
>> a) a "business" case of throwing anything other than AttributeError from
>> __getattr__ and friends is almost certainly a bug waiting to happen, and
>>
>> b) making the proposed change is bound to break real, production code.
> 
> I agree with. This is why the change is not making its way into any
> maintenance release.
> 
> 
> 
+1

regards
 Steve
-- 
Steve Holden           +1 571 484 6266   +1 800 494 3119
DjangoCon US September 7-9, 2010    http://djangocon.us/
See Python Video!       http://python.mirocommunity.org/
Holden Web LLC                 http://www.holdenweb.com/

From steve at holdenweb.com  Tue Aug 24 16:49:07 2010
From: steve at holdenweb.com (Steve Holden)
Date: Tue, 24 Aug 2010 10:49:07 -0400
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <AANLkTik-uikSKVy9PEoZTJS+k4r5Fn1KMjv0qiZ0ALYD@mail.gmail.com>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>	<AANLkTimo2u2xGm3DjT7KU4uHM+_0JuwdjsQtCSYow15z@mail.gmail.com>	<AANLkTi=9E3_Bo1X9_gPxaK5dUrA=whmZbBdHY+Qknt_S@mail.gmail.com>	<4C73A92D.4050503@avl.com>	<AANLkTik+q=smAPGhd3yHFBtk5G4TrtzvqdFnQFN5cvpB@mail.gmail.com>	<4C73CB0C.3060600@avl.com>
	<AANLkTik-uikSKVy9PEoZTJS+k4r5Fn1KMjv0qiZ0ALYD@mail.gmail.com>
Message-ID: <4C73DBE3.1020704@holdenweb.com>

On 8/24/2010 9:45 AM, Benjamin Peterson wrote:
> 2010/8/24 Hrvoje Niksic <hrvoje.niksic at avl.com>:
>> On 08/24/2010 02:31 PM, Benjamin Peterson wrote:
>>>
>>> 2010/8/24 Hrvoje Niksic<hrvoje.niksic at avl.com>:
>>>>
>>>>  The __length_hint__ lookup expects either no exception or
>>>> AttributeError,
>>>>  and will propagate others.  I'm not sure if this is a bug.  On the one
>>>> hand,
>>>>  throwing anything except AttributeError from __getattr__ is bad style
>>>> (which
>>>>  is why we fixed the bug by deriving our business exception from
>>>>  AttributeError), but the __length_hint__ check is supposed to be an
>>>> internal
>>>>  optimization completely invisible to the caller of list().
>>>
>>> __length_hint__ is internal and undocumented, so it can do whatever it
>>> wants.
>>
>> Of course, but that's beside the point.  In this case __length_hint__ was
>> neither implemented in the class, nor were we aware of its existence, and
>> the code still broke (as in the example in previous mail).  The point I'm
>> making is that:
>>
>> a) a "business" case of throwing anything other than AttributeError from
>> __getattr__ and friends is almost certainly a bug waiting to happen, and
>>
>> b) making the proposed change is bound to break real, production code.
> 
> I agree with. This is why the change is not making its way into any
> maintenance release.
> 
> 
> 
+1

regards
 Steve
-- 
Steve Holden           +1 571 484 6266   +1 800 494 3119
DjangoCon US September 7-9, 2010    http://djangocon.us/
See Python Video!       http://python.mirocommunity.org/
Holden Web LLC                 http://www.holdenweb.com/


From guido at python.org  Tue Aug 24 16:50:58 2010
From: guido at python.org (Guido van Rossum)
Date: Tue, 24 Aug 2010 07:50:58 -0700
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <201008242151.21940.steve@pearwood.info>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
	<201008240956.27584.steve@pearwood.info>
	<AANLkTi=qHnY3ugXKurzO1hhCBOCjXBEpqd+O8TW93VT+@mail.gmail.com>
	<201008242151.21940.steve@pearwood.info>
Message-ID: <AANLkTin+kC5n-RujsQ1Td+zH5Kr2PBDnpsZKM+qjXb-P@mail.gmail.com>

On Tue, Aug 24, 2010 at 4:51 AM, Steven D'Aprano <steve at pearwood.info> wrote:
> But that's the thing... as far as I am concerned, a dynamically defined
> attribute *doesn't* exist. If it existed, __getattr__ would never be
> called. A minor semantic difference, to be sure, but it's real to me.

Eh? If "x.y" succeeds, in what sense does y not exist?

> Whether I should care about the difference is a separate issue.

Right, you are breaking through too much abstraction.

> Performance could be an issue, of course, if somebody writes an
> expensive __getattr__ or property. Computed attributes should be cheap.

Yes, and it should be considered the problem of the author of that
property, not of the user.

> But I'm actually more concerned about side-effects than performance.

Properties should not have side effects. That would be a problem when
using them just as much as with hasattr().

-- 
--Guido van Rossum (python.org/~guido)

From rdmurray at bitdance.com  Tue Aug 24 16:57:20 2010
From: rdmurray at bitdance.com (R. David Murray)
Date: Tue, 24 Aug 2010 10:57:20 -0400
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <AANLkTi=rkL8Kv3tkC=GxERsVDxVVzrRQJc_KWgOj0k+B@mail.gmail.com>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
	<AANLkTimo2u2xGm3DjT7KU4uHM+_0JuwdjsQtCSYow15z@mail.gmail.com>
	<AANLkTi=9E3_Bo1X9_gPxaK5dUrA=whmZbBdHY+Qknt_S@mail.gmail.com>
	<4C73A92D.4050503@avl.com>
	<AANLkTik+q=smAPGhd3yHFBtk5G4TrtzvqdFnQFN5cvpB@mail.gmail.com>
	<4C73CB0C.3060600@avl.com>
	<20100824142212.494343A40A5@sparrow.telecommunity.com>
	<AANLkTi=rkL8Kv3tkC=GxERsVDxVVzrRQJc_KWgOj0k+B@mail.gmail.com>
Message-ID: <20100824145720.9738921F3D0@kimball.webabinitio.net>

On Tue, 24 Aug 2010 09:26:09 -0500, Benjamin Peterson <benjamin at python.org> wrote:
> 2010/8/24 P.J. Eby <pje at telecommunity.com>:
> > At 03:37 PM 8/24/2010 +0200, Hrvoje Niksic wrote:
> >>
> >> a) a "business" case of throwing anything other than AttributeError from
> >> __getattr__ and friends is almost certainly a bug waiting to happen, and
> >
> > FYI, best practice for __getattr__ is generally to bail with an
> > AttributeError as soon as you see double underscores in the name, unless you
> > intend to support special attributes.
> 
> Unless you're in an old-style class, you shouldn't get an double
> underscore methods in __getattr__ (or __getattribute__). If you do,
> it's a bug.

Benjamin, I remember you fixing various special method lookups, so just
for clarity's sake, which versions of Python does your statement apply to?

--
R. David Murray                                      www.bitdance.com

From benjamin at python.org  Tue Aug 24 17:08:32 2010
From: benjamin at python.org (Benjamin Peterson)
Date: Tue, 24 Aug 2010 10:08:32 -0500
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <20100824145720.9738921F3D0@kimball.webabinitio.net>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
	<AANLkTimo2u2xGm3DjT7KU4uHM+_0JuwdjsQtCSYow15z@mail.gmail.com>
	<AANLkTi=9E3_Bo1X9_gPxaK5dUrA=whmZbBdHY+Qknt_S@mail.gmail.com>
	<4C73A92D.4050503@avl.com>
	<AANLkTik+q=smAPGhd3yHFBtk5G4TrtzvqdFnQFN5cvpB@mail.gmail.com>
	<4C73CB0C.3060600@avl.com>
	<20100824142212.494343A40A5@sparrow.telecommunity.com>
	<AANLkTi=rkL8Kv3tkC=GxERsVDxVVzrRQJc_KWgOj0k+B@mail.gmail.com>
	<20100824145720.9738921F3D0@kimball.webabinitio.net>
Message-ID: <AANLkTi=woaPh43SKsXqzb6ZWAR990vThLCSjD7Mh-rQV@mail.gmail.com>

2010/8/24 R. David Murray <rdmurray at bitdance.com>:
> On Tue, 24 Aug 2010 09:26:09 -0500, Benjamin Peterson <benjamin at python.org> wrote:
>> 2010/8/24 P.J. Eby <pje at telecommunity.com>:
>> > At 03:37 PM 8/24/2010 +0200, Hrvoje Niksic wrote:
>> >>
>> >> a) a "business" case of throwing anything other than AttributeError from
>> >> __getattr__ and friends is almost certainly a bug waiting to happen, and
>> >
>> > FYI, best practice for __getattr__ is generally to bail with an
>> > AttributeError as soon as you see double underscores in the name, unless you
>> > intend to support special attributes.
>>
>> Unless you're in an old-style class, you shouldn't get an double
>> underscore methods in __getattr__ (or __getattribute__). If you do,
>> it's a bug.
>
> Benjamin, I remember you fixing various special method lookups, so just
> for clarity's sake, which versions of Python does your statement apply to?

2.7, 3.1, and 3.2 should all be good.


-- 
Regards,
Benjamin

From foom at fuhm.net  Tue Aug 24 16:42:21 2010
From: foom at fuhm.net (James Y Knight)
Date: Tue, 24 Aug 2010 10:42:21 -0400
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <AANLkTi=rkL8Kv3tkC=GxERsVDxVVzrRQJc_KWgOj0k+B@mail.gmail.com>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
	<AANLkTimo2u2xGm3DjT7KU4uHM+_0JuwdjsQtCSYow15z@mail.gmail.com>
	<AANLkTi=9E3_Bo1X9_gPxaK5dUrA=whmZbBdHY+Qknt_S@mail.gmail.com>
	<4C73A92D.4050503@avl.com>
	<AANLkTik+q=smAPGhd3yHFBtk5G4TrtzvqdFnQFN5cvpB@mail.gmail.com>
	<4C73CB0C.3060600@avl.com>
	<20100824142212.494343A40A5@sparrow.telecommunity.com>
	<AANLkTi=rkL8Kv3tkC=GxERsVDxVVzrRQJc_KWgOj0k+B@mail.gmail.com>
Message-ID: <849CA97A-DE5F-4D7D-9542-DB25BA3DFD72@fuhm.net>


On Aug 24, 2010, at 10:26 AM, Benjamin Peterson wrote:

> 2010/8/24 P.J. Eby <pje at telecommunity.com>:
>> At 03:37 PM 8/24/2010 +0200, Hrvoje Niksic wrote:
>>>
>>> a) a "business" case of throwing anything other than  
>>> AttributeError from
>>> __getattr__ and friends is almost certainly a bug waiting to  
>>> happen, and
>>
>> FYI, best practice for __getattr__ is generally to bail with an
>> AttributeError as soon as you see double underscores in the name,  
>> unless you
>> intend to support special attributes.
>
> Unless you're in an old-style class, you shouldn't get an double
> underscore methods in __getattr__ (or __getattribute__). If you do,
> it's a bug.

Uh, did you see the message that was in response to?

Maybe it should be a bug report?

 >>> class Foo(object):
...  def __getattr__(self, name): print "ATTR:",name
...  def __iter__(self): yield 1
...
 >>> print list(Foo())
ATTR: __length_hint__
[1]

James

From benjamin at python.org  Tue Aug 24 17:13:31 2010
From: benjamin at python.org (Benjamin Peterson)
Date: Tue, 24 Aug 2010 10:13:31 -0500
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <849CA97A-DE5F-4D7D-9542-DB25BA3DFD72@fuhm.net>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
	<AANLkTimo2u2xGm3DjT7KU4uHM+_0JuwdjsQtCSYow15z@mail.gmail.com>
	<AANLkTi=9E3_Bo1X9_gPxaK5dUrA=whmZbBdHY+Qknt_S@mail.gmail.com>
	<4C73A92D.4050503@avl.com>
	<AANLkTik+q=smAPGhd3yHFBtk5G4TrtzvqdFnQFN5cvpB@mail.gmail.com>
	<4C73CB0C.3060600@avl.com>
	<20100824142212.494343A40A5@sparrow.telecommunity.com>
	<AANLkTi=rkL8Kv3tkC=GxERsVDxVVzrRQJc_KWgOj0k+B@mail.gmail.com>
	<849CA97A-DE5F-4D7D-9542-DB25BA3DFD72@fuhm.net>
Message-ID: <AANLkTima+oj3MfJ72UfC8XNQPZ90Mg+gv1sESf-dcpap@mail.gmail.com>

2010/8/24 James Y Knight <foom at fuhm.net>:
>
> On Aug 24, 2010, at 10:26 AM, Benjamin Peterson wrote:
>
>> 2010/8/24 P.J. Eby <pje at telecommunity.com>:
>>>
>>> At 03:37 PM 8/24/2010 +0200, Hrvoje Niksic wrote:
>>>>
>>>> a) a "business" case of throwing anything other than AttributeError from
>>>> __getattr__ and friends is almost certainly a bug waiting to happen, and
>>>
>>> FYI, best practice for __getattr__ is generally to bail with an
>>> AttributeError as soon as you see double underscores in the name, unless
>>> you
>>> intend to support special attributes.
>>
>> Unless you're in an old-style class, you shouldn't get an double
>> underscore methods in __getattr__ (or __getattribute__). If you do,
>> it's a bug.
>
> Uh, did you see the message that was in response to?
>
> Maybe it should be a bug report?

Old version of Python I think.



-- 
Regards,
Benjamin

From pje at telecommunity.com  Tue Aug 24 17:55:41 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Tue, 24 Aug 2010 11:55:41 -0400
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <AANLkTima+oj3MfJ72UfC8XNQPZ90Mg+gv1sESf-dcpap@mail.gmail.c
 om>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
	<AANLkTimo2u2xGm3DjT7KU4uHM+_0JuwdjsQtCSYow15z@mail.gmail.com>
	<AANLkTi=9E3_Bo1X9_gPxaK5dUrA=whmZbBdHY+Qknt_S@mail.gmail.com>
	<4C73A92D.4050503@avl.com>
	<AANLkTik+q=smAPGhd3yHFBtk5G4TrtzvqdFnQFN5cvpB@mail.gmail.com>
	<4C73CB0C.3060600@avl.com>
	<20100824142212.494343A40A5@sparrow.telecommunity.com>
	<AANLkTi=rkL8Kv3tkC=GxERsVDxVVzrRQJc_KWgOj0k+B@mail.gmail.com>
	<849CA97A-DE5F-4D7D-9542-DB25BA3DFD72@fuhm.net>
	<AANLkTima+oj3MfJ72UfC8XNQPZ90Mg+gv1sESf-dcpap@mail.gmail.com>
Message-ID: <20100824155546.AA5593A40A5@sparrow.telecommunity.com>

At 10:13 AM 8/24/2010 -0500, Benjamin Peterson wrote:
>2010/8/24 James Y Knight <foom at fuhm.net>:
> >
> > On Aug 24, 2010, at 10:26 AM, Benjamin Peterson wrote:
> >
> >> 2010/8/24 P.J. Eby <pje at telecommunity.com>:
> >>>
> >>> At 03:37 PM 8/24/2010 +0200, Hrvoje Niksic wrote:
> >>>>
> >>>> a) a "business" case of throwing anything other than AttributeError from
> >>>> __getattr__ and friends is almost certainly a bug waiting to happen, and
> >>>
> >>> FYI, best practice for __getattr__ is generally to bail with an
> >>> AttributeError as soon as you see double underscores in the name, unless
> >>> you
> >>> intend to support special attributes.
> >>
> >> Unless you're in an old-style class, you shouldn't get an double
> >> underscore methods in __getattr__ (or __getattribute__). If you do,
> >> it's a bug.
> >
> > Uh, did you see the message that was in response to?
> >
> > Maybe it should be a bug report?
>
>Old version of Python I think.

If by "old" you mean 2.6, sure.  (Also, I did say this was a best 
practice since 2.2.)


From cool-rr at cool-rr.com  Tue Aug 24 18:19:48 2010
From: cool-rr at cool-rr.com (cool-RR)
Date: Tue, 24 Aug 2010 18:19:48 +0200
Subject: [Python-Dev] Generating "canonical argument call" from `getargspec`
 and `getcallargs` results
Message-ID: <AANLkTimsy9b6FCqb46iua5Rja1uEkti=_mNKE5WcbA7H@mail.gmail.com>

I was happy to see the new `getcallargs` function in the `inspect` module.
But there's one thing I want to do that's related to it, and maybe this was
implemented somewhere or someone can give me some pointers about it.

I want to have a function that takes the results of `getargspec` and
`getcallargs` for a function and a set of arguments, and outputs the
"canonical argument call" that would generate these results.

For example, let's say I have a function `f`:

    def f(a, b, c=7, **kwargs):
        pass

This is its argument spec:

    >>> inspect.getargspec(f)
    ArgSpec(args=['a', 'b', 'c'], varargs=None, keywords='kwargs',
defaults=(7,))

Now, different argument combinations can generate the same results
`getcallargs` result

    >>> inspect.getcallargs(f, 1, 2, 7, meow='grrr') # Like calling f(1, 2,
7, meow='grrr')
    {'a': 1, 'c': 7, 'b': 2, 'kwargs': {'meow': 'grrr'}}

    >>> inspect.getcallargs(f, 1, 2, meow='grrr') # Like calling f(1, 2,
meow='grrr')
    {'a': 1, 'c': 7, 'b': 2, 'kwargs': {'meow': 'grrr'}}

    >>> inspect.getcallargs(f, 1, b=2, c=7, meow='grrr') # Like calling f(1,
b=2, c=7, meow='grrr')
    {'a': 1, 'c': 7, 'b': 2, 'kwargs': {'meow': 'grrr'}}

What I would like to have is one canonical argument combination. I assume
that the best way to define the canonical form is "The smallest number of
arguments, and specifying as few keyword arguments as possible." According
to that definition, the canonical argument call in the above example would
be the second one, `f(1, 2, meow='grrr')`.

So I want a function that for a given function and argument call, returns
the canonical argument call, which generates the same `getcallargs` result
as the given argument call.

The reason I want this is to make it easier to organize a set of argument
calls. (I'm doing an application in which the user maintains a set of
argument profiles that he can choose from, and having to deal with only the
canonical form will prevent some annoyances.)

Did anyone implement something like this? Does anyone have ideas? And is
this something that would be of interest to the standard library?


Best Wishes,
Ram Rachum.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100824/97f3913f/attachment.html>

From glyph at twistedmatrix.com  Tue Aug 24 20:11:34 2010
From: glyph at twistedmatrix.com (Glyph Lefkowitz)
Date: Tue, 24 Aug 2010 14:11:34 -0400
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <AANLkTik+q=smAPGhd3yHFBtk5G4TrtzvqdFnQFN5cvpB@mail.gmail.com>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
	<AANLkTimo2u2xGm3DjT7KU4uHM+_0JuwdjsQtCSYow15z@mail.gmail.com>
	<AANLkTi=9E3_Bo1X9_gPxaK5dUrA=whmZbBdHY+Qknt_S@mail.gmail.com>
	<4C73A92D.4050503@avl.com>
	<AANLkTik+q=smAPGhd3yHFBtk5G4TrtzvqdFnQFN5cvpB@mail.gmail.com>
Message-ID: <A765D595-E381-480E-85E9-ED84EFC9CB83@twistedmatrix.com>


On Aug 24, 2010, at 8:31 AM, Benjamin Peterson wrote:

> 2010/8/24 Hrvoje Niksic <hrvoje.niksic at avl.com>:
>> The __length_hint__ lookup expects either no exception or AttributeError,
>> and will propagate others.  I'm not sure if this is a bug.  On the one hand,
>> throwing anything except AttributeError from __getattr__ is bad style (which
>> is why we fixed the bug by deriving our business exception from
>> AttributeError), but the __length_hint__ check is supposed to be an internal
>> optimization completely invisible to the caller of list().
> 
> __length_hint__ is internal and undocumented, so it can do whatever it wants.

As it happens though, list() is _quite_ public.  Saying "X is internal and undocumented, so it can do whatever it wants" is never really realistic, especially in response to someone saying "we already saw this problem in production, _without_ calling / referring to / knowing about this private API".

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100824/1a37a8dc/attachment.html>

From barry at python.org  Tue Aug 24 21:31:46 2010
From: barry at python.org (Barry Warsaw)
Date: Tue, 24 Aug 2010 15:31:46 -0400
Subject: [Python-Dev] Released: Python 2.6.6
Message-ID: <20100824153146.69874f04@heresy>

Hello fellow Pythoneers and Pythonistas,

I'm very happy to announce the release of Python 2.6.6.  A truly impressive
number of bugs have been fixed since Python 2.6.5.  Source code and Windows
installers for Python 2.6.6 are now available here:

    http://www.python.org/download/releases/2.6.6/

The full details of everything that's changed is available in the NEWS file:

    http://www.python.org/download/releases/2.6.6/NEWS.txt

Python 2.6.6 marks the end of regular maintenance releases for the Python 2.6
series.  From now until October 2013, only security related, source-only
releases of Python 2.6 will be made available.  After that date, Python 2.6
will no longer be supported, even for security bugs.

My deepest appreciation go out to everyone who has helped contribute fixes
great and small, and much testing and bug tracker gardening for Python 2.6.6.

Enjoy,
-Barry
(on behalf of the Python development community)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100824/9120ccb7/attachment.pgp>

From nagle at animats.com  Tue Aug 24 21:37:42 2010
From: nagle at animats.com (John Nagle)
Date: Tue, 24 Aug 2010 12:37:42 -0700
Subject: [Python-Dev] Python-Dev Digest, Vol 85, Issue 71
In-Reply-To: <mailman.1.1282635612.4650.python-dev@python.org>
References: <mailman.1.1282635612.4650.python-dev@python.org>
Message-ID: <4C741F86.2000701@animats.com>

On 8/24/2010 12:40 AM, python-dev-request at python.org wrote:
> Message: 4 Date: Mon, 23 Aug 2010 17:21:50 -0700 From: Brett Cannon
> <brett at python.org>
> It is also non-obvious to any beginner. Are we really going to want to
> propagate the knowledge of this trick as a fundamental idiom? I would
> rather leave hasattr in that instance. But I'm +1 on only swallowing
> AttributeError.

    I'd argue that since the ability to inherit a class from "dict"
was added, dynamically adding attributes is somewhat obsolete.
An object instance is not a dictionary.  Especially since its
namespace interacts with the namespace of its class.

    I've been using Google Code Search to look at the actual use
cases for "setattr".  The main uses are:

    1.  Copying.  Object copying is done with "setattr".
        All the "setattr" objects occur during object
        construction, or shortly after.

    2.  Creating proxy objects for remote access.  This is
        much like copying,

    3.  Representing HTML objects as
        Python object.  This usually requies gyrations to
        avoid clashes with Python built-in names and
        functions; "class" is a common attribute in
        HTML, and a reserved word in Python, and some hack
        is necessary to make that work.  BeautifulSoup
        does this.

It's rare that attributes are added long after object
construction.  Perhaps a mechanism should be provided for
dynamically constructing an object.  Something like

	class foo(object) :
		pass

	attrdict = { a : 1, b : 2}
	make_object(foo, attrdict)

This covers most of the use cases for "setattr".

					John Nagle

From raymond.hettinger at gmail.com  Tue Aug 24 22:40:11 2010
From: raymond.hettinger at gmail.com (Raymond Hettinger)
Date: Tue, 24 Aug 2010 13:40:11 -0700
Subject: [Python-Dev] Released: Python 2.6.6
In-Reply-To: <20100824153146.69874f04@heresy>
References: <20100824153146.69874f04@heresy>
Message-ID: <FC867A24-4FF5-4D18-838F-38C8BA9E4A8A@gmail.com>


On Aug 24, 2010, at 12:31 PM, Barry Warsaw wrote:

> Hello fellow Pythoneers and Pythonistas,
> 
> I'm very happy to announce the release of Python 2.6.6.  

Thanks Barry :-)


Raymond

From ncoghlan at gmail.com  Tue Aug 24 00:39:37 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 24 Aug 2010 08:39:37 +1000
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <AANLkTinw-tk+CzJrkY63p74H5iEuSvHDuPn+6PH0XP7r@mail.gmail.com>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
	<2C284C09-3819-4858-A75A-34597DD668B7@gmail.com>
	<AANLkTimFeoZsRdUfWfhSyievK_819KFRoqDO2H3sc2JN@mail.gmail.com>
	<4C72D552.2030306@voidspace.org.uk>
	<AANLkTinzZ40ykb+JHFFJ9W=4ww5AwiLnd=_s5pVgqVaN@mail.gmail.com>
	<65FC8A3B-F9AF-4ED9-B63C-41335EF49E1A@gmail.com>
	<AANLkTiniuGQpt6dS4wi1yUBcBP2GZPDdStzL39T-kkFt@mail.gmail.com>
	<4C72E1F2.2020209@voidspace.org.uk>
	<44CF7603-7F55-4AA5-8C61-F0E34D0D0EE2@gmail.com>
	<AANLkTikAXvBq9dL7uj9k_+w7BgUQ+UK4oPpWZoqhHBwf@mail.gmail.com>
	<BD2CCE2A-7E62-4D39-AF09-0CC6809F8CAB@gmail.com>
	<AANLkTimM-02=+dfTW=zRdRM3Cryqy35jeiz6aRc4y4k8@mail.gmail.com>
	<13D815C6-248F-44FE-83B9-65C85685072A@gmail.com>
	<AANLkTinw-tk+CzJrkY63p74H5iEuSvHDuPn+6PH0XP7r@mail.gmail.com>
Message-ID: <AANLkTi=AaZHHjSzVo3wB90zW-4s2j0KRA3W7zVGaHt2O@mail.gmail.com>

On Tue, Aug 24, 2010 at 8:25 AM, Benjamin Peterson <benjamin at python.org> wrote:
> 2010/8/23 Yury Selivanov <yselivanov at gmail.com>:
>> So, the proposed magic method is not intended to change the protocol,
>> but to complement and enhance it.
>
> But it still raises the potential to break the relationship between
> hasattr and getattr.
>
> I think this should require a PEP.

Definitely needs a PEP, and will require some solid use cases to
explain why allowing optimisation of hasattr() is the right way to go.
Complexity isn't free, and I doubt the gains here will justify the
costs, but that's one of the things the PEP process is intended to
figure out.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From ncoghlan at gmail.com  Tue Aug 24 00:25:03 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 24 Aug 2010 08:25:03 +1000
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <AANLkTikSKdYRu5kJDxLT-m4Y_bM33mY+kWaBawyreTRo@mail.gmail.com>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
	<2C284C09-3819-4858-A75A-34597DD668B7@gmail.com>
	<AANLkTimFeoZsRdUfWfhSyievK_819KFRoqDO2H3sc2JN@mail.gmail.com>
	<4C72D552.2030306@voidspace.org.uk>
	<AANLkTinzZ40ykb+JHFFJ9W=4ww5AwiLnd=_s5pVgqVaN@mail.gmail.com>
	<65FC8A3B-F9AF-4ED9-B63C-41335EF49E1A@gmail.com>
	<AANLkTiniuGQpt6dS4wi1yUBcBP2GZPDdStzL39T-kkFt@mail.gmail.com>
	<4C72E1F2.2020209@voidspace.org.uk>
	<AANLkTimGMunx9uEJMqDrQYLjKAOmypWQoOuACLDpWkGQ@mail.gmail.com>
	<4C72E372.5060201@voidspace.org.uk>
	<AANLkTiniWduAnWfmw+rV06fWAUYGNj4USce_cTOsoBgW@mail.gmail.com>
	<AANLkTikSKdYRu5kJDxLT-m4Y_bM33mY+kWaBawyreTRo@mail.gmail.com>
Message-ID: <AANLkTik8Ld2z-QsiT0=c0zWwUNyw_pAQkROMpUGJXHth@mail.gmail.com>

On Tue, Aug 24, 2010 at 8:15 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> Now, it may be worth considering an addition to the inspect module
> that was basically:
>
> def getattr_static(obj, attr):
> ? ?"""Retrieve attributes without triggering dynamic lookup via the
> descriptor protocol,
> ? ? ? ?__getattr__ or __getattribute__.
>
> ? ? ? ?Note: this function may not be able to retrieve all attributes
> reported by dir(obj)
> ? ?"""
> ? ?try:
> ? ? ? ?instance_dict = object.__getattribute__(obj, "__dict__")
> ? ?except AttributeError:
> ? ? ? ?pass
> ? ?else:
> ? ? ? ?if attr in instance_dict:
> ? ? ? ? ? ?return instance_dict[attr]
> ? ?for entry in getmro(obj.__class__):
> ? ? ? ?try:
> ? ? ? ? ? ?return entry.__dict__[attr]
> ? ? ? ?except AttributeError:
> ? ? ? ? ? ?pass

Second attempt with a default value parameter and correctly raising
AttributeError if not found:

_sentinel = object()
def getattr_static(obj, attr, default=_sentinel):
    """Retrieve attributes without triggering dynamic lookup via the
        descriptor protocol,  __getattr__ or __getattribute__.

        Note: this function may not be able to retrieve all attributes
        reported by dir(obj)
    """
    try:
        instance_dict = object.__getattribute__(obj, "__dict__")
    except AttributeError:
        pass
    else:
        if attr in instance_dict:
            return instance_dict[attr]
    for entry in getmro(obj.__class__):
        try:
            return entry.__dict__[attr]
        except AttributeError:
            pass
    if default is not _sentinel:
        return default
    raise AttributeError(attr)

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From ncoghlan at gmail.com  Tue Aug 24 00:15:19 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 24 Aug 2010 08:15:19 +1000
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <AANLkTiniWduAnWfmw+rV06fWAUYGNj4USce_cTOsoBgW@mail.gmail.com>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
	<2C284C09-3819-4858-A75A-34597DD668B7@gmail.com>
	<AANLkTimFeoZsRdUfWfhSyievK_819KFRoqDO2H3sc2JN@mail.gmail.com>
	<4C72D552.2030306@voidspace.org.uk>
	<AANLkTinzZ40ykb+JHFFJ9W=4ww5AwiLnd=_s5pVgqVaN@mail.gmail.com>
	<65FC8A3B-F9AF-4ED9-B63C-41335EF49E1A@gmail.com>
	<AANLkTiniuGQpt6dS4wi1yUBcBP2GZPDdStzL39T-kkFt@mail.gmail.com>
	<4C72E1F2.2020209@voidspace.org.uk>
	<AANLkTimGMunx9uEJMqDrQYLjKAOmypWQoOuACLDpWkGQ@mail.gmail.com>
	<4C72E372.5060201@voidspace.org.uk>
	<AANLkTiniWduAnWfmw+rV06fWAUYGNj4USce_cTOsoBgW@mail.gmail.com>
Message-ID: <AANLkTikSKdYRu5kJDxLT-m4Y_bM33mY+kWaBawyreTRo@mail.gmail.com>

On Tue, Aug 24, 2010 at 7:40 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> Properties are allowed to do whatever the heck they want. That doesn't mean
>> that you have to execute code to determine whether they exist or not.
>
> If you don't want to execute properties, do the lookup on the type,
> not the instance (obviously, you know the dance you need to do, since
> you've linked the code where you did it). Having apparently simple
> query operations like hasattr/getattr/len/etc execute arbitrary code
> is where much of the language's flexibility comes from, so I don't see
> how it can really be surprising when it happens.

Now, it may be worth considering an addition to the inspect module
that was basically:

def getattr_static(obj, attr):
    """Retrieve attributes without triggering dynamic lookup via the
descriptor protocol,
        __getattr__ or __getattribute__.

        Note: this function may not be able to retrieve all attributes
reported by dir(obj)
    """
    try:
        instance_dict = object.__getattribute__(obj, "__dict__")
    except AttributeError:
        pass
    else:
        if attr in instance_dict:
            return instance_dict[attr]
    for entry in getmro(obj.__class__):
        try:
            return entry.__dict__[attr]
        except AttributeError:
            pass

(not needing to deal with classic classes simplifies things a bit)

So, allowing for the fact that dir() may report attributes that can
only be found via dynamic lookup, your get_docstrings example could
become something like:

def get_docstrings(obj):
    try:
        members = dir(obj)
    except Exception:
        members = []
    for member in members:
        try:
            doc = getattr_static(obj, member).__doc__
        except AttributeError:
            doc = None
        yield member, doc

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From ncoghlan at gmail.com  Tue Aug 24 00:17:20 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 24 Aug 2010 08:17:20 +1000
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <4C72ECDC.8080104@voidspace.org.uk>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
	<2C284C09-3819-4858-A75A-34597DD668B7@gmail.com>
	<AANLkTimFeoZsRdUfWfhSyievK_819KFRoqDO2H3sc2JN@mail.gmail.com>
	<4C72D552.2030306@voidspace.org.uk>
	<AANLkTinzZ40ykb+JHFFJ9W=4ww5AwiLnd=_s5pVgqVaN@mail.gmail.com>
	<65FC8A3B-F9AF-4ED9-B63C-41335EF49E1A@gmail.com>
	<AANLkTiniuGQpt6dS4wi1yUBcBP2GZPDdStzL39T-kkFt@mail.gmail.com>
	<4C72E1F2.2020209@voidspace.org.uk>
	<AANLkTimGMunx9uEJMqDrQYLjKAOmypWQoOuACLDpWkGQ@mail.gmail.com>
	<4C72E372.5060201@voidspace.org.uk>
	<AANLkTiniWduAnWfmw+rV06fWAUYGNj4USce_cTOsoBgW@mail.gmail.com>
	<4C72ECDC.8080104@voidspace.org.uk>
Message-ID: <AANLkTim9Po1Db199MJ8h4tvoazpBN9rtGjZB4qC4JNmi@mail.gmail.com>

On Tue, Aug 24, 2010 at 7:49 AM, Michael Foord
<fuzzyman at voidspace.org.uk> wrote:
> Certainly that is true for len. getattr obviously involves invoking code if
> you are fetching a property or descriptor. No idea how you conclude that
> hasattr executing code adds flexibility to the language though.

Proxy objects like the one in the weakref module don't work if
hasattr() doesn't implicitly invoke __getattr__.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From barry at python.org  Wed Aug 25 01:12:40 2010
From: barry at python.org (Barry Warsaw)
Date: Tue, 24 Aug 2010 19:12:40 -0400
Subject: [Python-Dev] Released: Python 2.6.6
In-Reply-To: <20100824153146.69874f04@heresy>
References: <20100824153146.69874f04@heresy>
Message-ID: <20100824191240.1457a3f0@heresy>

On Aug 24, 2010, at 03:31 PM, Barry Warsaw wrote:

>Python 2.6.6 marks the end of regular maintenance releases for the
>Python 2.6 series.  From now until October 2013, only security
>related, source-only releases of Python 2.6 will be made available.
>After that date, Python 2.6 will no longer be supported, even for
>security bugs.

merwok asks on IRC whether documentation changes to release26-maint will be
allowed.  I can sympathize with the 'allow' argument; Python 2.6 is still
either the default version or soon to be the new default in several
distributions, and it will take a while before Python 2.7 is as widely
available.

I can also sympathize with the 'disallow' argument; it's more work for
everybody because it effectively means the branch is still open, and I will
probably have to push out new docs every now and then.

OTOH, I suspect there won't be *that* many documentation fixes for Python 2.6
and that the overhead will be minimal.  What did we do for Python 2.5?  I'm
willing to support consensus, and if that means allowing documentation fixes,
I'll accept the extra RM work.  OTOH, I won't cry too much if the consensus is
to not allow them.

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100824/7b9fdc12/attachment.pgp>

From greg.ewing at canterbury.ac.nz  Wed Aug 25 02:10:02 2010
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Wed, 25 Aug 2010 12:10:02 +1200
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <201008242151.21940.steve@pearwood.info>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
	<201008240956.27584.steve@pearwood.info>
	<AANLkTi=qHnY3ugXKurzO1hhCBOCjXBEpqd+O8TW93VT+@mail.gmail.com>
	<201008242151.21940.steve@pearwood.info>
Message-ID: <4C745F5A.4030909@canterbury.ac.nz>

Steven D'Aprano wrote:

> But that's the thing... as far as I am concerned, a dynamically defined 
> attribute *doesn't* exist.

Maybe for your particular use case, but the concept of
whether an attribute is dynamically defined or not is
not well-defined in general.

Consider an object that is trying to be a transparent
proxy for another object, and behave as much as possible
as though it really were the other object. Should an
attribute statically defined on the proxied object be
considered dynamically defined on the proxy? If so, then
the proxy isn't as transparent as some people may want.

-- 
Greg

From victor.stinner at haypocalc.com  Wed Aug 25 02:42:37 2010
From: victor.stinner at haypocalc.com (Victor Stinner)
Date: Wed, 25 Aug 2010 02:42:37 +0200
Subject: [Python-Dev] Released: Python 2.6.6
In-Reply-To: <20100824191240.1457a3f0@heresy>
References: <20100824153146.69874f04@heresy> <20100824191240.1457a3f0@heresy>
Message-ID: <201008250242.37323.victor.stinner@haypocalc.com>

Le mercredi 25 ao?t 2010 01:12:40, Barry Warsaw a ?crit :
> merwok asks on IRC whether documentation changes to release26-maint will be
> allowed.  I can sympathize with the 'allow' argument; Python 2.6 is still
> either the default version or soon to be the new default in several
> distributions, and it will take a while before Python 2.7 is as widely
> available.

Even if I use Python 2.5, I read 2.7 doc because it is usually more complete 
(eg. 2.7 has more examples). If I use a new function, I just check that it is 
not a function introduced in Python 2.6 or 2.7.

If you compare 2.5 and 2.7 doc, the 2.5 is just ugly :-) 2.5 has no table of 
content at the left and it uses subpages which is less pratical (to search 
something using the browser) that a whole module on the same page.

So I just don't care of 2.6 doc :-)

-- 
Victor Stinner
http://www.haypocalc.com/

From martin at v.loewis.de  Wed Aug 25 08:03:40 2010
From: martin at v.loewis.de (=?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 25 Aug 2010 08:03:40 +0200
Subject: [Python-Dev] Released: Python 2.6.6
In-Reply-To: <20100824191240.1457a3f0@heresy>
References: <20100824153146.69874f04@heresy> <20100824191240.1457a3f0@heresy>
Message-ID: <4C74B23C.1010203@v.loewis.de>

> OTOH, I suspect there won't be *that* many documentation fixes for Python 2.6
> and that the overhead will be minimal.  What did we do for Python 2.5?

The question really is whether there is any chance that they will get
released, in some form. There won't be further binary releases (at least
not from python.org), so there definitely won't be a CHM release.

For 2.5, I didn't do releases of the documentation for security
releases. You might decide to make it differently, i.e. including
doc sets with the security releases. If you are not going to release
the documentation (which I would recommend), then committers should
be advised not to commit changes to the documentation (as they will
not get releases).

I do fail to see the point in favor of making documentation changes.
Sure, 2.7 isn't yet widely available. However, 2.6 users should
generally be fine with the 2.6.6 doc set - will the minor changes
that we can make to it (given that no bug fixes will be made to the
code) really matter?

Regards,
Martin

From adal.chiriliuc at gmail.com  Wed Aug 25 17:03:36 2010
From: adal.chiriliuc at gmail.com (Adal Chiriliuc)
Date: Wed, 25 Aug 2010 18:03:36 +0300
Subject: [Python-Dev] CHM filename (was  Released: Python 2.6.6)
Message-ID: <AANLkTim2zU_6Rx75FGUB2B5FPhy6wPDQfCPQ0q+0RPdp@mail.gmail.com>

> The question really is whether there is any chance that they will get
> released, in some form. There won't be further binary releases (at least
> not from python.org), so there definitely won't be a CHM release.

Speaking about the CHM, why does it include the version number in it's filename?
Why isn't it named python.chm instead of python266.chm, just like we have
python.exe and not python266.exe?

I have shortcut links in the QuickLaunch area to the documentation for
quick access and in a different launcher program. Each time I upgrade
Python I must update them because of the embedded version number.

Regards,
Adal

From merwok at netwok.org  Wed Aug 25 17:32:56 2010
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Wed, 25 Aug 2010 17:32:56 +0200
Subject: [Python-Dev] Released: Python 2.6.6
In-Reply-To: <4C74B23C.1010203@v.loewis.de>
References: <20100824153146.69874f04@heresy> <20100824191240.1457a3f0@heresy>
	<4C74B23C.1010203@v.loewis.de>
Message-ID: <4C7537A8.5070602@netwok.org>

> The question really is whether there is any chance that they will get
> released, in some form. There won't be further binary releases (at least
> not from python.org), so there definitely won't be a CHM release.

I think that the most important release is docs.python.org/2.6,
regardless of python.org/OS-specific downloadable doc packages.

If people do like haypo and use the most recent docs instead of the
version-specific ones, there?s indeed no need to bother with porting doc
fixes and improvements. If people use docs.py.org/2.6 as a reference for
some years while 2.7 is not on their systems, it may be worthwhile to
keep updating those docs.

Regards


From alexis at notmyidea.org  Wed Aug 25 18:19:24 2010
From: alexis at notmyidea.org (=?UTF-8?B?QWxleGlzIE3DqXRhaXJlYXU=?=)
Date: Wed, 25 Aug 2010 18:19:24 +0200
Subject: [Python-Dev] Released: Python 2.6.6
In-Reply-To: <4C7537A8.5070602@netwok.org>
References: <20100824153146.69874f04@heresy>
	<20100824191240.1457a3f0@heresy>	<4C74B23C.1010203@v.loewis.de>
	<4C7537A8.5070602@netwok.org>
Message-ID: <4C75428C.50702@notmyidea.org>

 Le 08/25/2010 05:32 PM, ?ric Araujo a ?crit :
> I think that the most important release is docs.python.org/2.6,
> regardless of python.org/OS-specific downloadable doc packages.
>
> If people do like haypo and use the most recent docs instead of the
> version-specific ones, there?s indeed no need to bother with porting doc
> fixes and improvements. If people use docs.py.org/2.6 as a reference for
> some years while 2.7 is not on their systems, it may be worthwhile to
> keep updating those docs.
We can also, recommend to always rely on the last version somewhere,
if it's the best way to go.

This way, we can avoid those questions in the future.

I like how the django project present their documentation: there is
a little informational text at the head of each doc, saying that
"you're not browsing the most up-to-date documentation, you can
find the last one here"; maybe can we do a similar thing for the python
doc ?

Regards,
Alexis

From pje at telecommunity.com  Wed Aug 25 18:27:38 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Wed, 25 Aug 2010 12:27:38 -0400
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <4C745F5A.4030909@canterbury.ac.nz>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
	<201008240956.27584.steve@pearwood.info>
	<AANLkTi=qHnY3ugXKurzO1hhCBOCjXBEpqd+O8TW93VT+@mail.gmail.com>
	<201008242151.21940.steve@pearwood.info>
	<4C745F5A.4030909@canterbury.ac.nz>
Message-ID: <20100825162746.078483A40A4@sparrow.telecommunity.com>

At 12:10 PM 8/25/2010 +1200, Greg Ewing wrote:
>Consider an object that is trying to be a transparent
>proxy for another object, and behave as much as possible
>as though it really were the other object. Should an
>attribute statically defined on the proxied object be
>considered dynamically defined on the proxy? If so, then
>the proxy isn't as transparent as some people may want.

Yep.  That's why the proposed addition to inspect is a bad idea.  If 
we encourage that sort of static thinking, it will lead to people 
creating all sorts of breakage with respect to more dynamic code.

AFAICT, the whole "avoid running code" thing only makes sense for a 
debugging tool -- at which point, you can always use the trace 
facility and throw an error when any Python code runs that's not part 
of your debugging tool.  Something like:

def exists(ob, attr):
    __running__ = True
    # ... set trace function here
    try:
        try:
            getattr(ob, attr)
            return True
        except AttributeError:
            return False
        except CodeRanError:
             return True   # or False if you prefer
    finally:
        __running__ = False
        # restore old tracing here

Where the trace function is just something that throws CodeRanError 
if it detects a "call" event and the __running__ flag is True.  This 
would stop any Python code from actually executing.  (It'd need to 
keep the same trace function for c_call events, since that might lead 
to nested non-C calls .)

Of course, a debugger's object inspection tool would probably 
actually want to return either the attribute value, or a special 
value to mean "dyanmic calculation needed".


From fuzzyman at voidspace.org.uk  Wed Aug 25 19:58:20 2010
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Wed, 25 Aug 2010 20:58:20 +0300
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <20100825162746.078483A40A4@sparrow.telecommunity.com>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>	<201008240956.27584.steve@pearwood.info>	<AANLkTi=qHnY3ugXKurzO1hhCBOCjXBEpqd+O8TW93VT+@mail.gmail.com>	<201008242151.21940.steve@pearwood.info>	<4C745F5A.4030909@canterbury.ac.nz>
	<20100825162746.078483A40A4@sparrow.telecommunity.com>
Message-ID: <4C7559BC.9020807@voidspace.org.uk>

  On 25/08/2010 19:27, P.J. Eby wrote:
> At 12:10 PM 8/25/2010 +1200, Greg Ewing wrote:
>> Consider an object that is trying to be a transparent
>> proxy for another object, and behave as much as possible
>> as though it really were the other object. Should an
>> attribute statically defined on the proxied object be
>> considered dynamically defined on the proxy? If so, then
>> the proxy isn't as transparent as some people may want.
>
> Yep.  That's why the proposed addition to inspect is a bad idea.  If 
> we encourage that sort of static thinking, it will lead to people 
> creating all sorts of breakage with respect to more dynamic code.
>
> AFAICT, the whole "avoid running code" thing only makes sense for a 
> debugging tool 

I mentioned another use case - pulling out docstrings. IDEs or other 
tools that work with live objects may have many such use cases.

For proxying objects you can't use the __getattr__ approach for the 
"magic methods" which aren't looked up through the dynamic attribute 
'faking' process. Several proxy libraries I've seen get round this by 
providing *every* magic method on the proxy class and delegating. This 
still breaks certain types of duck typing. For example with Python 2.6:

 >>> class x(object):
...  @property
...  def __call__(self):
...   raise AttributeError
...
 >>> a = x()
 >>> callable(a)
True


If your proxy class defines __call__ then callable returns True, even if 
the delegation to the proxied object would cause an AttributeError to be 
raised. A *better* approach (IMO), for both the magic methods and the 
normal attributes / methods, is to dynamically generate a class that 
mimics the proxied object (caching generated classes for proxying 
objects of the same type if you are worried about overhead). This would 
also work with the suggested "passive introspection" function.

All the best,

Michael Foord


> -- at which point, you can always use the trace facility and throw an 
> error when any Python code runs that's not part of your debugging 
> tool.  Something like:
>
> def exists(ob, attr):
>    __running__ = True
>    # ... set trace function here
>    try:
>        try:
>            getattr(ob, attr)
>            return True
>        except AttributeError:
>            return False
>        except CodeRanError:
>             return True   # or False if you prefer
>    finally:
>        __running__ = False
>        # restore old tracing here
>
> Where the trace function is just something that throws CodeRanError if 
> it detects a "call" event and the __running__ flag is True.  This 
> would stop any Python code from actually executing.  (It'd need to 
> keep the same trace function for c_call events, since that might lead 
> to nested non-C calls .)
>
> Of course, a debugger's object inspection tool would probably actually 
> want to return either the attribute value, or a special value to mean 
> "dyanmic calculation needed".
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at 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/


From adijbr at gmail.com  Wed Aug 25 19:59:44 2010
From: adijbr at gmail.com (Alcino Dall'Igna Jr)
Date: Wed, 25 Aug 2010 14:59:44 -0300
Subject: [Python-Dev] Fwd:  i18n
In-Reply-To: <AANLkTim62674F3w-c8gaUggco0uuwJAD_a+7b-DGrgRN@mail.gmail.com>
References: <AANLkTinv=a8f3kO56CJ3FUgSZPh23fuSs7zyaofj=GMM@mail.gmail.com>
	<20100814081816.GC49566@nexus.in-nomine.org>
	<AANLkTinAYVWrqw2tO3DaY7rb+n8xLQgv6ri_RkxwYCJH@mail.gmail.com>
	<AANLkTim62674F3w-c8gaUggco0uuwJAD_a+7b-DGrgRN@mail.gmail.com>
Message-ID: <AANLkTi=Ss+ZK_GnxrkaC_O-YAHMDxWHL34qVAcvAJvu1@mail.gmail.com>

To those beginners in programming that are not?English?speakers there
are 3 problems to be solved:
1) the logic (this is?unavoidable)
2) the programming language (hard but quite simple)
3) the messages (hard and not simple)

Those who could not cope with (1) could not be programmers

(2)?difficult?but not the main (so a 2nd step)

(3) the worst but more?treatable and more largely useful

The i18n of (2) is mainly to be used in initial stages and could not
be generally?applicable?(maybe just some?European?languages).?This
probably?could require to rewrote the scanner (or maybe only the
grammar, I haven't gone so deep yet) so it's not that big of a
problem, it hardly affects the parser and interpreter, that are the
more complex tasks.

If (3) could enter the main trunk it would be a great help by itself.
In this case access to international help is useless due the original
difficulties with the language, remember I'm talking about kids
mainly, and 1st stage to programming for youngsters. There are two
main ways to do this, one is using codes as indicated, but I prefer
using the more generally accepted and used, with messages catalogs
using gettext and the like.

Any way thanks for your comments.

Alcino

2010/8/17 Anders Sandvig <anders.sandvig at gmail.com>
>
> On Sat, Aug 14, 2010 at 10:18 AM, Jeroen Ruigrok van der Werven
> <asmodai at in-nomine.org> wrote:
> > I doubt you will be able to localize much with regard to the interpreter.
> > The only thing that really comes to mind are the error and exception
> > messages, but you will never be able to localize the errors themselves. The
> > problem there is that if they seek help on international fora for Python,
> > other people might have no clue what the (error) message even means.
>
> I think one way to solve this might be to include the original
> (English) error message as well as the translation. I've noticed this
> is how error messages are handled in localized versions of Oracle, and
> although I'm personally annoyed by it, I can see how some people might
> find it useful.
>
> For example:
>
> >>> cause.error()
> Traceback (most recent call last):
> ? ?File "<stdin>", line 1, in <module>
> NameError: name 'cause' is not defined
>
> localized to Norwegian, could become:
>
> >>> cause.error()
> Tilbakesporing (nyeste kall sist):
> ? ?Fil "<stdin>", linje 1, i <module>
> NameError: navn 'cause' er ikke definert (name 'cause' is not defined)
>
> I think translating the actual error text would make sense, but I'm
> not so sure about localizing the traceback output itself...
>
>
> Anders

From guido at python.org  Wed Aug 25 20:26:05 2010
From: guido at python.org (Guido van Rossum)
Date: Wed, 25 Aug 2010 11:26:05 -0700
Subject: [Python-Dev] Fwd: i18n
In-Reply-To: <AANLkTi=Ss+ZK_GnxrkaC_O-YAHMDxWHL34qVAcvAJvu1@mail.gmail.com>
References: <AANLkTinv=a8f3kO56CJ3FUgSZPh23fuSs7zyaofj=GMM@mail.gmail.com>
	<20100814081816.GC49566@nexus.in-nomine.org>
	<AANLkTinAYVWrqw2tO3DaY7rb+n8xLQgv6ri_RkxwYCJH@mail.gmail.com>
	<AANLkTim62674F3w-c8gaUggco0uuwJAD_a+7b-DGrgRN@mail.gmail.com>
	<AANLkTi=Ss+ZK_GnxrkaC_O-YAHMDxWHL34qVAcvAJvu1@mail.gmail.com>
Message-ID: <AANLkTimq5vF3WqpDZHe1W4ruYiNb1qbYFgRha8iSUEaF@mail.gmail.com>

On Wed, Aug 25, 2010 at 10:59 AM, Alcino Dall'Igna Jr <adijbr at gmail.com> wrote:
> To those beginners in programming that are not?English?speakers there
> are 3 problems to be solved:
> 1) the logic (this is?unavoidable)
> 2) the programming language (hard but quite simple)
> 3) the messages (hard and not simple)
>
> Those who could not cope with (1) could not be programmers
>
> (2)?difficult?but not the main (so a 2nd step)
>
> (3) the worst but more?treatable and more largely useful
>
> The i18n of (2) is mainly to be used in initial stages and could not
> be generally?applicable?(maybe just some?European?languages).?This
> probably?could require to rewrote the scanner (or maybe only the
> grammar, I haven't gone so deep yet) so it's not that big of a
> problem, it hardly affects the parser and interpreter, that are the
> more complex tasks.

IMO (2) is a bad idea. You'd have to translate not just the keywords
but also the builtins and the standard library. Or else your users
would still live in a mixed-world and the benefit would be minimal.
But translating the stdlib is too much work. (It can't be fully
automated, due to things like getattr(x, 'foo').) There's also the
danger that users would write code in their local dialect and expect
to share it with others in another locale. Let them read and write
broken English, it's unavoidable anyway! (Probably they know more
broken English than you think. After all they are using computers
already. :-)

> If (3) could enter the main trunk it would be a great help by itself.
> In this case access to international help is useless due the original
> difficulties with the language, remember I'm talking about kids
> mainly, and 1st stage to programming for youngsters. There are two
> main ways to do this, one is using codes as indicated, but I prefer
> using the more generally accepted and used, with messages catalogs
> using gettext and the like.

That sounds painful, but in general I am okay with the idea of
translating messages. I think the system messages (those that go with
IOError and OSError) may already be translated. How to do it without
off-putting the core developers may end up being a research problem.
:-)

-- 
--Guido van Rossum (python.org/~guido)

From fuzzyman at voidspace.org.uk  Wed Aug 25 20:31:22 2010
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Wed, 25 Aug 2010 21:31:22 +0300
Subject: [Python-Dev] Fwd: i18n
In-Reply-To: <AANLkTimq5vF3WqpDZHe1W4ruYiNb1qbYFgRha8iSUEaF@mail.gmail.com>
References: <AANLkTinv=a8f3kO56CJ3FUgSZPh23fuSs7zyaofj=GMM@mail.gmail.com>	<20100814081816.GC49566@nexus.in-nomine.org>	<AANLkTinAYVWrqw2tO3DaY7rb+n8xLQgv6ri_RkxwYCJH@mail.gmail.com>	<AANLkTim62674F3w-c8gaUggco0uuwJAD_a+7b-DGrgRN@mail.gmail.com>	<AANLkTi=Ss+ZK_GnxrkaC_O-YAHMDxWHL34qVAcvAJvu1@mail.gmail.com>
	<AANLkTimq5vF3WqpDZHe1W4ruYiNb1qbYFgRha8iSUEaF@mail.gmail.com>
Message-ID: <4C75617A.6050204@voidspace.org.uk>

  On 25/08/2010 21:26, Guido van Rossum wrote:
> [snip...]
>> If (3) could enter the main trunk it would be a great help by itself.
>> In this case access to international help is useless due the original
>> difficulties with the language, remember I'm talking about kids
>> mainly, and 1st stage to programming for youngsters. There are two
>> main ways to do this, one is using codes as indicated, but I prefer
>> using the more generally accepted and used, with messages catalogs
>> using gettext and the like.
> That sounds painful, but in general I am okay with the idea of
> translating messages. I think the system messages (those that go with
> IOError and OSError) may already be translated. How to do it without
> off-putting the core developers may end up being a research problem.
> :-)
>

+1 - a difficult problem to solve (socially and architecturally but not 
technologically) but users are likely to appreciate it.

A downside (from experience with .NET which takes this approach - logic 
and class names are all English but error messages are localized) is 
that you then get bug reports with localized error messages. It makes 
frequent visits to google translate unavoidable...

All the best,

Michael

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


From pje at telecommunity.com  Wed Aug 25 21:57:12 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Wed, 25 Aug 2010 15:57:12 -0400
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <4C7559BC.9020807@voidspace.org.uk>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
	<201008240956.27584.steve@pearwood.info>
	<AANLkTi=qHnY3ugXKurzO1hhCBOCjXBEpqd+O8TW93VT+@mail.gmail.com>
	<201008242151.21940.steve@pearwood.info>
	<4C745F5A.4030909@canterbury.ac.nz>
	<20100825162746.078483A40A4@sparrow.telecommunity.com>
	<4C7559BC.9020807@voidspace.org.uk>
Message-ID: <20100825195722.506873A411C@sparrow.telecommunity.com>

At 08:58 PM 8/25/2010 +0300, Michael Foord wrote:
>If your proxy class defines __call__ then callable returns True, 
>even if the delegation to the proxied object would cause an 
>AttributeError to be raised.

Nope.  You just have to use delegate via __getattribute__ (since 2.2) 
instead of __getattr__:

 >>> from peak.util.proxies import ObjectProxy
 >>> o=ObjectProxy(lambda:1)
 >>> o()
1
 >>> o.__call__
<method-wrapper '__call__' of function object at 0x00E004B0>

 >>> o=ObjectProxy(1)
 >>> o()
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
   File 
"c:\cygwin\home\pje\projects\proxytypes\peak\util\proxies.py", line 6, in
  __call__
     return self.__subject__(*args,**kw)
TypeError: 'int' object is not callable

 >>> o.__call__
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
   File 
"c:\cygwin\home\pje\projects\proxytypes\peak\util\proxies.py", line 12, i
n __getattribute__
     return getattr(subject,attr)
AttributeError: 'int' object has no attribute '__call__'


As you can see, the __call__ attribute in each case is whatever the 
proxied object's __call__ attribute is, even though the proxy itself 
has a __call__ method, that is invoked when the proxy is called.

This is actually pretty straightforward stuff since the introduction 
of __getattribute__.

(The code is at http://pypi.python.org/pypi/ProxyTypes, btw.)


From tjreedy at udel.edu  Wed Aug 25 22:26:04 2010
From: tjreedy at udel.edu (Terry Reedy)
Date: Wed, 25 Aug 2010 16:26:04 -0400
Subject: [Python-Dev] Fwd: i18n
In-Reply-To: <4C75617A.6050204@voidspace.org.uk>
References: <AANLkTinv=a8f3kO56CJ3FUgSZPh23fuSs7zyaofj=GMM@mail.gmail.com>	<20100814081816.GC49566@nexus.in-nomine.org>	<AANLkTinAYVWrqw2tO3DaY7rb+n8xLQgv6ri_RkxwYCJH@mail.gmail.com>	<AANLkTim62674F3w-c8gaUggco0uuwJAD_a+7b-DGrgRN@mail.gmail.com>	<AANLkTi=Ss+ZK_GnxrkaC_O-YAHMDxWHL34qVAcvAJvu1@mail.gmail.com>	<AANLkTimq5vF3WqpDZHe1W4ruYiNb1qbYFgRha8iSUEaF@mail.gmail.com>
	<4C75617A.6050204@voidspace.org.uk>
Message-ID: <i53u8r$fol$1@dough.gmane.org>

On 8/25/2010 2:31 PM, Michael Foord wrote:
> On 25/08/2010 21:26, Guido van Rossum wrote:
>> [snip...]

>> That sounds painful, but in general I am okay with the idea of
>> translating messages. I think the system messages (those that go with
>> IOError and OSError) may already be translated. How to do it without
>> off-putting the core developers may end up being a research problem.
>> :-)
>>
>
> +1 - a difficult problem to solve (socially and architecturally but not
> technologically) but users are likely to appreciate it.
>
> A downside (from experience with .NET which takes this approach - logic
> and class names are all English but error messages are localized) is
> that you then get bug reports with localized error messages. It makes
> frequent visits to google translate unavoidable...

Localized messages should be in addition to rather than a replacement 
for the English version. I thought we had this discussion somewhere -- 
here? ideas? maybe a tracker issue?

-- 
Terry Jan Reedy


From ncoghlan at gmail.com  Tue Aug 24 00:39:37 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 24 Aug 2010 08:39:37 +1000
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <AANLkTinw-tk+CzJrkY63p74H5iEuSvHDuPn+6PH0XP7r@mail.gmail.com>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
	<2C284C09-3819-4858-A75A-34597DD668B7@gmail.com>
	<AANLkTimFeoZsRdUfWfhSyievK_819KFRoqDO2H3sc2JN@mail.gmail.com>
	<4C72D552.2030306@voidspace.org.uk>
	<AANLkTinzZ40ykb+JHFFJ9W=4ww5AwiLnd=_s5pVgqVaN@mail.gmail.com>
	<65FC8A3B-F9AF-4ED9-B63C-41335EF49E1A@gmail.com>
	<AANLkTiniuGQpt6dS4wi1yUBcBP2GZPDdStzL39T-kkFt@mail.gmail.com>
	<4C72E1F2.2020209@voidspace.org.uk>
	<44CF7603-7F55-4AA5-8C61-F0E34D0D0EE2@gmail.com>
	<AANLkTikAXvBq9dL7uj9k_+w7BgUQ+UK4oPpWZoqhHBwf@mail.gmail.com>
	<BD2CCE2A-7E62-4D39-AF09-0CC6809F8CAB@gmail.com>
	<AANLkTimM-02=+dfTW=zRdRM3Cryqy35jeiz6aRc4y4k8@mail.gmail.com>
	<13D815C6-248F-44FE-83B9-65C85685072A@gmail.com>
	<AANLkTinw-tk+CzJrkY63p74H5iEuSvHDuPn+6PH0XP7r@mail.gmail.com>
Message-ID: <AANLkTi=AaZHHjSzVo3wB90zW-4s2j0KRA3W7zVGaHt2O@mail.gmail.com>

On Tue, Aug 24, 2010 at 8:25 AM, Benjamin Peterson <benjamin at python.org> wrote:
> 2010/8/23 Yury Selivanov <yselivanov at gmail.com>:
>> So, the proposed magic method is not intended to change the protocol,
>> but to complement and enhance it.
>
> But it still raises the potential to break the relationship between
> hasattr and getattr.
>
> I think this should require a PEP.

Definitely needs a PEP, and will require some solid use cases to
explain why allowing optimisation of hasattr() is the right way to go.
Complexity isn't free, and I doubt the gains here will justify the
costs, but that's one of the things the PEP process is intended to
figure out.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From ncoghlan at gmail.com  Tue Aug 24 00:25:03 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 24 Aug 2010 08:25:03 +1000
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <AANLkTikSKdYRu5kJDxLT-m4Y_bM33mY+kWaBawyreTRo@mail.gmail.com>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
	<2C284C09-3819-4858-A75A-34597DD668B7@gmail.com>
	<AANLkTimFeoZsRdUfWfhSyievK_819KFRoqDO2H3sc2JN@mail.gmail.com>
	<4C72D552.2030306@voidspace.org.uk>
	<AANLkTinzZ40ykb+JHFFJ9W=4ww5AwiLnd=_s5pVgqVaN@mail.gmail.com>
	<65FC8A3B-F9AF-4ED9-B63C-41335EF49E1A@gmail.com>
	<AANLkTiniuGQpt6dS4wi1yUBcBP2GZPDdStzL39T-kkFt@mail.gmail.com>
	<4C72E1F2.2020209@voidspace.org.uk>
	<AANLkTimGMunx9uEJMqDrQYLjKAOmypWQoOuACLDpWkGQ@mail.gmail.com>
	<4C72E372.5060201@voidspace.org.uk>
	<AANLkTiniWduAnWfmw+rV06fWAUYGNj4USce_cTOsoBgW@mail.gmail.com>
	<AANLkTikSKdYRu5kJDxLT-m4Y_bM33mY+kWaBawyreTRo@mail.gmail.com>
Message-ID: <AANLkTik8Ld2z-QsiT0=c0zWwUNyw_pAQkROMpUGJXHth@mail.gmail.com>

On Tue, Aug 24, 2010 at 8:15 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> Now, it may be worth considering an addition to the inspect module
> that was basically:
>
> def getattr_static(obj, attr):
> ? ?"""Retrieve attributes without triggering dynamic lookup via the
> descriptor protocol,
> ? ? ? ?__getattr__ or __getattribute__.
>
> ? ? ? ?Note: this function may not be able to retrieve all attributes
> reported by dir(obj)
> ? ?"""
> ? ?try:
> ? ? ? ?instance_dict = object.__getattribute__(obj, "__dict__")
> ? ?except AttributeError:
> ? ? ? ?pass
> ? ?else:
> ? ? ? ?if attr in instance_dict:
> ? ? ? ? ? ?return instance_dict[attr]
> ? ?for entry in getmro(obj.__class__):
> ? ? ? ?try:
> ? ? ? ? ? ?return entry.__dict__[attr]
> ? ? ? ?except AttributeError:
> ? ? ? ? ? ?pass

Second attempt with a default value parameter and correctly raising
AttributeError if not found:

_sentinel = object()
def getattr_static(obj, attr, default=_sentinel):
    """Retrieve attributes without triggering dynamic lookup via the
        descriptor protocol,  __getattr__ or __getattribute__.

        Note: this function may not be able to retrieve all attributes
        reported by dir(obj)
    """
    try:
        instance_dict = object.__getattribute__(obj, "__dict__")
    except AttributeError:
        pass
    else:
        if attr in instance_dict:
            return instance_dict[attr]
    for entry in getmro(obj.__class__):
        try:
            return entry.__dict__[attr]
        except AttributeError:
            pass
    if default is not _sentinel:
        return default
    raise AttributeError(attr)

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From ncoghlan at gmail.com  Tue Aug 24 00:15:19 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 24 Aug 2010 08:15:19 +1000
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <AANLkTiniWduAnWfmw+rV06fWAUYGNj4USce_cTOsoBgW@mail.gmail.com>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
	<2C284C09-3819-4858-A75A-34597DD668B7@gmail.com>
	<AANLkTimFeoZsRdUfWfhSyievK_819KFRoqDO2H3sc2JN@mail.gmail.com>
	<4C72D552.2030306@voidspace.org.uk>
	<AANLkTinzZ40ykb+JHFFJ9W=4ww5AwiLnd=_s5pVgqVaN@mail.gmail.com>
	<65FC8A3B-F9AF-4ED9-B63C-41335EF49E1A@gmail.com>
	<AANLkTiniuGQpt6dS4wi1yUBcBP2GZPDdStzL39T-kkFt@mail.gmail.com>
	<4C72E1F2.2020209@voidspace.org.uk>
	<AANLkTimGMunx9uEJMqDrQYLjKAOmypWQoOuACLDpWkGQ@mail.gmail.com>
	<4C72E372.5060201@voidspace.org.uk>
	<AANLkTiniWduAnWfmw+rV06fWAUYGNj4USce_cTOsoBgW@mail.gmail.com>
Message-ID: <AANLkTikSKdYRu5kJDxLT-m4Y_bM33mY+kWaBawyreTRo@mail.gmail.com>

On Tue, Aug 24, 2010 at 7:40 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> Properties are allowed to do whatever the heck they want. That doesn't mean
>> that you have to execute code to determine whether they exist or not.
>
> If you don't want to execute properties, do the lookup on the type,
> not the instance (obviously, you know the dance you need to do, since
> you've linked the code where you did it). Having apparently simple
> query operations like hasattr/getattr/len/etc execute arbitrary code
> is where much of the language's flexibility comes from, so I don't see
> how it can really be surprising when it happens.

Now, it may be worth considering an addition to the inspect module
that was basically:

def getattr_static(obj, attr):
    """Retrieve attributes without triggering dynamic lookup via the
descriptor protocol,
        __getattr__ or __getattribute__.

        Note: this function may not be able to retrieve all attributes
reported by dir(obj)
    """
    try:
        instance_dict = object.__getattribute__(obj, "__dict__")
    except AttributeError:
        pass
    else:
        if attr in instance_dict:
            return instance_dict[attr]
    for entry in getmro(obj.__class__):
        try:
            return entry.__dict__[attr]
        except AttributeError:
            pass

(not needing to deal with classic classes simplifies things a bit)

So, allowing for the fact that dir() may report attributes that can
only be found via dynamic lookup, your get_docstrings example could
become something like:

def get_docstrings(obj):
    try:
        members = dir(obj)
    except Exception:
        members = []
    for member in members:
        try:
            doc = getattr_static(obj, member).__doc__
        except AttributeError:
            doc = None
        yield member, doc

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From ncoghlan at gmail.com  Tue Aug 24 00:17:20 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 24 Aug 2010 08:17:20 +1000
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <4C72ECDC.8080104@voidspace.org.uk>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
	<2C284C09-3819-4858-A75A-34597DD668B7@gmail.com>
	<AANLkTimFeoZsRdUfWfhSyievK_819KFRoqDO2H3sc2JN@mail.gmail.com>
	<4C72D552.2030306@voidspace.org.uk>
	<AANLkTinzZ40ykb+JHFFJ9W=4ww5AwiLnd=_s5pVgqVaN@mail.gmail.com>
	<65FC8A3B-F9AF-4ED9-B63C-41335EF49E1A@gmail.com>
	<AANLkTiniuGQpt6dS4wi1yUBcBP2GZPDdStzL39T-kkFt@mail.gmail.com>
	<4C72E1F2.2020209@voidspace.org.uk>
	<AANLkTimGMunx9uEJMqDrQYLjKAOmypWQoOuACLDpWkGQ@mail.gmail.com>
	<4C72E372.5060201@voidspace.org.uk>
	<AANLkTiniWduAnWfmw+rV06fWAUYGNj4USce_cTOsoBgW@mail.gmail.com>
	<4C72ECDC.8080104@voidspace.org.uk>
Message-ID: <AANLkTim9Po1Db199MJ8h4tvoazpBN9rtGjZB4qC4JNmi@mail.gmail.com>

On Tue, Aug 24, 2010 at 7:49 AM, Michael Foord
<fuzzyman at voidspace.org.uk> wrote:
> Certainly that is true for len. getattr obviously involves invoking code if
> you are fetching a property or descriptor. No idea how you conclude that
> hasattr executing code adds flexibility to the language though.

Proxy objects like the one in the weakref module don't work if
hasattr() doesn't implicitly invoke __getattr__.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From ncoghlan at gmail.com  Wed Aug 25 23:41:10 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 26 Aug 2010 07:41:10 +1000
Subject: [Python-Dev] Fwd: i18n
In-Reply-To: <i53u8r$fol$1@dough.gmane.org>
References: <AANLkTinv=a8f3kO56CJ3FUgSZPh23fuSs7zyaofj=GMM@mail.gmail.com>
	<20100814081816.GC49566@nexus.in-nomine.org>
	<AANLkTinAYVWrqw2tO3DaY7rb+n8xLQgv6ri_RkxwYCJH@mail.gmail.com>
	<AANLkTim62674F3w-c8gaUggco0uuwJAD_a+7b-DGrgRN@mail.gmail.com>
	<AANLkTi=Ss+ZK_GnxrkaC_O-YAHMDxWHL34qVAcvAJvu1@mail.gmail.com>
	<AANLkTimq5vF3WqpDZHe1W4ruYiNb1qbYFgRha8iSUEaF@mail.gmail.com>
	<4C75617A.6050204@voidspace.org.uk> <i53u8r$fol$1@dough.gmane.org>
Message-ID: <AANLkTikqGiFKS7pjitKCj1yC1WOCj4NCTVzN1i8aHRss@mail.gmail.com>

On Thu, Aug 26, 2010 at 6:26 AM, Terry Reedy <tjreedy at udel.edu> wrote:
> On 8/25/2010 2:31 PM, Michael Foord wrote:
>> A downside (from experience with .NET which takes this approach - logic
>> and class names are all English but error messages are localized) is
>> that you then get bug reports with localized error messages. It makes
>> frequent visits to google translate unavoidable...
>
> Localized messages should be in addition to rather than a replacement for
> the English version. I thought we had this discussion somewhere -- here?
> ideas? maybe a tracker issue?

I remember the same discussion, and yeah, the final position was that
including the original English text along with the localised text made
the most sense. The idea didn't really go anywhere after that though,
since it is still a *lot* of work.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From martin at v.loewis.de  Thu Aug 26 00:08:34 2010
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 26 Aug 2010 00:08:34 +0200
Subject: [Python-Dev] CHM filename (was  Released: Python 2.6.6)
In-Reply-To: <AANLkTim2zU_6Rx75FGUB2B5FPhy6wPDQfCPQ0q+0RPdp@mail.gmail.com>
References: <AANLkTim2zU_6Rx75FGUB2B5FPhy6wPDQfCPQ0q+0RPdp@mail.gmail.com>
Message-ID: <4C759462.1040405@v.loewis.de>

Am 25.08.2010 17:03, schrieb Adal Chiriliuc:
>> The question really is whether there is any chance that they will get
>> released, in some form. There won't be further binary releases (at least
>> not from python.org), so there definitely won't be a CHM release.
> 
> Speaking about the CHM, why does it include the version number in it's filename?

Wrt. software, any "why" question is tricky. It's in the file name
because the generator that generates it puts it there.

Now, why does it put it there? Because it does so for any other
distribution format of the documentation. It used to be python26.chm
(i.e. without the micro version), and was deliberately changed -
primarily for consistency, AFAIK.

Now, why do the other formats have a version number in them? So that you
can have them all in the same directory, and they won't overwrite each
other. And so that if you downloaded one of them, you'd still know what
it is that you downloaded afterwards.

Regards,
Martin

From martin at v.loewis.de  Thu Aug 26 00:33:24 2010
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Thu, 26 Aug 2010 00:33:24 +0200
Subject: [Python-Dev] Released: Python 2.6.6
In-Reply-To: <4C75428C.50702@notmyidea.org>
References: <20100824153146.69874f04@heresy>	<20100824191240.1457a3f0@heresy>	<4C74B23C.1010203@v.loewis.de>	<4C7537A8.5070602@netwok.org>
	<4C75428C.50702@notmyidea.org>
Message-ID: <4C759A34.1070603@v.loewis.de>

> I like how the django project present their documentation: there is
> a little informational text at the head of each doc, saying that
> "you're not browsing the most up-to-date documentation, you can
> find the last one here"; maybe can we do a similar thing for the python
> doc ?

In principle, yes. However, it is really tricky to say what the "last
one" is: is 3.1 more recent that 2.7, or not? When 3.2 is released:
should the 2.6 documentation point to 2.7, or 3.2?

If you would now propose to merely have a link from the 2.6 version
to both 2.7 and 3.2: that link is already there.

Regards,
Martin

From adal.chiriliuc at gmail.com  Thu Aug 26 01:28:04 2010
From: adal.chiriliuc at gmail.com (Adal Chiriliuc)
Date: Thu, 26 Aug 2010 02:28:04 +0300
Subject: [Python-Dev] CHM filename (was  Released: Python 2.6.6)
In-Reply-To: <4C759462.1040405@v.loewis.de>
References: <AANLkTim2zU_6Rx75FGUB2B5FPhy6wPDQfCPQ0q+0RPdp@mail.gmail.com>
	<4C759462.1040405@v.loewis.de>
Message-ID: <AANLkTikOEBohU0PPGfJ2AGj09QoiCgcoGXx+9qYixg+3@mail.gmail.com>

On Thu, Aug 26, 2010 at 1:08 AM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> Now, why do the other formats have a version number in them? So that you
> can have them all in the same directory, and they won't overwrite each
> other. And so that if you downloaded one of them, you'd still know what
> it is that you downloaded afterwards.

The one deployed with the binaries installer could still be renamed to
python.chm. When you start the CHM file, the first thing hitting you
is a huge "Python v2.6.5 documentation" header, so I don't think
anybody would be confused. And there doesn't seem to be a link to
download the CHM files (the last I could find on python.org is for
Python 2.6.2).

Anyway, this is not a big issue.

Regards,
Adal

From tjreedy at udel.edu  Thu Aug 26 02:04:21 2010
From: tjreedy at udel.edu (Terry Reedy)
Date: Wed, 25 Aug 2010 20:04:21 -0400
Subject: [Python-Dev] Fwd: i18n
In-Reply-To: <AANLkTikqGiFKS7pjitKCj1yC1WOCj4NCTVzN1i8aHRss@mail.gmail.com>
References: <AANLkTinv=a8f3kO56CJ3FUgSZPh23fuSs7zyaofj=GMM@mail.gmail.com>	<20100814081816.GC49566@nexus.in-nomine.org>	<AANLkTinAYVWrqw2tO3DaY7rb+n8xLQgv6ri_RkxwYCJH@mail.gmail.com>	<AANLkTim62674F3w-c8gaUggco0uuwJAD_a+7b-DGrgRN@mail.gmail.com>	<AANLkTi=Ss+ZK_GnxrkaC_O-YAHMDxWHL34qVAcvAJvu1@mail.gmail.com>	<AANLkTimq5vF3WqpDZHe1W4ruYiNb1qbYFgRha8iSUEaF@mail.gmail.com>	<4C75617A.6050204@voidspace.org.uk>
	<i53u8r$fol$1@dough.gmane.org>
	<AANLkTikqGiFKS7pjitKCj1yC1WOCj4NCTVzN1i8aHRss@mail.gmail.com>
Message-ID: <i54b25$1lo$1@dough.gmane.org>

On 8/25/2010 5:41 PM, Nick Coghlan wrote:
> On Thu, Aug 26, 2010 at 6:26 AM, Terry Reedy<tjreedy at udel.edu>  wrote:
>> On 8/25/2010 2:31 PM, Michael Foord wrote:
>>> A downside (from experience with .NET which takes this approach - logic
>>> and class names are all English but error messages are localized) is
>>> that you then get bug reports with localized error messages. It makes
>>> frequent visits to google translate unavoidable...
>>
>> Localized messages should be in addition to rather than a replacement for
>> the English version. I thought we had this discussion somewhere -- here?
>> ideas? maybe a tracker issue?
>
> I remember the same discussion, and yeah, the final position was that
> including the original English text along with the localised text made
> the most sense. The idea didn't really go anywhere after that though,
> since it is still a *lot* of work.

Just after posting, I went to python-list, and read a response from OP 
asked to paste the traceback for his problem:
...
   File "C:\Python26\lib\socket.py", line 406, in readline
     data = self._sock.recv(self._rbufsize)
socket.error: [Errno 10054] A l?tez? kapcsolatot a t?voli ?llom?s
k?nyszer?tette n bez?rta

Fortunately, the OP could translate back well enough to "So this message 
is meaning that the remote station forced close the existing 
connection." and get additional help from other respondents. So the 
idea, at least, of giving both versions would be a good one ;-).

-- 
Terry Jan Reedy



From nyamatongwe at gmail.com  Thu Aug 26 03:06:26 2010
From: nyamatongwe at gmail.com (Neil Hodgson)
Date: Thu, 26 Aug 2010 11:06:26 +1000
Subject: [Python-Dev] Fwd: i18n
In-Reply-To: <i54b25$1lo$1@dough.gmane.org>
References: <AANLkTinv=a8f3kO56CJ3FUgSZPh23fuSs7zyaofj=GMM@mail.gmail.com>
	<20100814081816.GC49566@nexus.in-nomine.org>
	<AANLkTinAYVWrqw2tO3DaY7rb+n8xLQgv6ri_RkxwYCJH@mail.gmail.com>
	<AANLkTim62674F3w-c8gaUggco0uuwJAD_a+7b-DGrgRN@mail.gmail.com>
	<AANLkTi=Ss+ZK_GnxrkaC_O-YAHMDxWHL34qVAcvAJvu1@mail.gmail.com>
	<AANLkTimq5vF3WqpDZHe1W4ruYiNb1qbYFgRha8iSUEaF@mail.gmail.com>
	<4C75617A.6050204@voidspace.org.uk> <i53u8r$fol$1@dough.gmane.org>
	<AANLkTikqGiFKS7pjitKCj1yC1WOCj4NCTVzN1i8aHRss@mail.gmail.com>
	<i54b25$1lo$1@dough.gmane.org>
Message-ID: <AANLkTi=dqdZ-uVhjdBjxLqFKX-vwrMCP9e4CmHGsnyPY@mail.gmail.com>

Terry Reedy:

> ?File "C:\Python26\lib\socket.py", line 406, in readline
> ? ?data = self._sock.recv(self._rbufsize)
> socket.error: [Errno 10054] A l?tez? kapcsolatot a t?voli ?llom?s
> k?nyszer?tette n bez?rta

   That is pretty good mojibake. One of the problems of providing
localized error messages is that the messages may be messed up at
different stages. The original text was
A l?tez? kapcsolatot a t?voli ?llom?s k?nyszer?tetten bez?rta.
   It was printed in iso8859_2 (ISO standard for Eastern European)
then those bytes were pasted in as if they were cp852 (MS-DOS Eastern
European).

text = "A l?tez? kapcsolatot a t?voli ?llom?s k?nyszer?tetten bez?rta."
print(str(text.encode('iso8859_2'), 'cp852'))

   Neil

From ncoghlan at gmail.com  Tue Aug 24 00:39:37 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 24 Aug 2010 08:39:37 +1000
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <AANLkTinw-tk+CzJrkY63p74H5iEuSvHDuPn+6PH0XP7r@mail.gmail.com>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
	<2C284C09-3819-4858-A75A-34597DD668B7@gmail.com>
	<AANLkTimFeoZsRdUfWfhSyievK_819KFRoqDO2H3sc2JN@mail.gmail.com>
	<4C72D552.2030306@voidspace.org.uk>
	<AANLkTinzZ40ykb+JHFFJ9W=4ww5AwiLnd=_s5pVgqVaN@mail.gmail.com>
	<65FC8A3B-F9AF-4ED9-B63C-41335EF49E1A@gmail.com>
	<AANLkTiniuGQpt6dS4wi1yUBcBP2GZPDdStzL39T-kkFt@mail.gmail.com>
	<4C72E1F2.2020209@voidspace.org.uk>
	<44CF7603-7F55-4AA5-8C61-F0E34D0D0EE2@gmail.com>
	<AANLkTikAXvBq9dL7uj9k_+w7BgUQ+UK4oPpWZoqhHBwf@mail.gmail.com>
	<BD2CCE2A-7E62-4D39-AF09-0CC6809F8CAB@gmail.com>
	<AANLkTimM-02=+dfTW=zRdRM3Cryqy35jeiz6aRc4y4k8@mail.gmail.com>
	<13D815C6-248F-44FE-83B9-65C85685072A@gmail.com>
	<AANLkTinw-tk+CzJrkY63p74H5iEuSvHDuPn+6PH0XP7r@mail.gmail.com>
Message-ID: <AANLkTi=AaZHHjSzVo3wB90zW-4s2j0KRA3W7zVGaHt2O@mail.gmail.com>

On Tue, Aug 24, 2010 at 8:25 AM, Benjamin Peterson <benjamin at python.org> wrote:
> 2010/8/23 Yury Selivanov <yselivanov at gmail.com>:
>> So, the proposed magic method is not intended to change the protocol,
>> but to complement and enhance it.
>
> But it still raises the potential to break the relationship between
> hasattr and getattr.
>
> I think this should require a PEP.

Definitely needs a PEP, and will require some solid use cases to
explain why allowing optimisation of hasattr() is the right way to go.
Complexity isn't free, and I doubt the gains here will justify the
costs, but that's one of the things the PEP process is intended to
figure out.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From ncoghlan at gmail.com  Tue Aug 24 00:25:03 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 24 Aug 2010 08:25:03 +1000
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <AANLkTikSKdYRu5kJDxLT-m4Y_bM33mY+kWaBawyreTRo@mail.gmail.com>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
	<2C284C09-3819-4858-A75A-34597DD668B7@gmail.com>
	<AANLkTimFeoZsRdUfWfhSyievK_819KFRoqDO2H3sc2JN@mail.gmail.com>
	<4C72D552.2030306@voidspace.org.uk>
	<AANLkTinzZ40ykb+JHFFJ9W=4ww5AwiLnd=_s5pVgqVaN@mail.gmail.com>
	<65FC8A3B-F9AF-4ED9-B63C-41335EF49E1A@gmail.com>
	<AANLkTiniuGQpt6dS4wi1yUBcBP2GZPDdStzL39T-kkFt@mail.gmail.com>
	<4C72E1F2.2020209@voidspace.org.uk>
	<AANLkTimGMunx9uEJMqDrQYLjKAOmypWQoOuACLDpWkGQ@mail.gmail.com>
	<4C72E372.5060201@voidspace.org.uk>
	<AANLkTiniWduAnWfmw+rV06fWAUYGNj4USce_cTOsoBgW@mail.gmail.com>
	<AANLkTikSKdYRu5kJDxLT-m4Y_bM33mY+kWaBawyreTRo@mail.gmail.com>
Message-ID: <AANLkTik8Ld2z-QsiT0=c0zWwUNyw_pAQkROMpUGJXHth@mail.gmail.com>

On Tue, Aug 24, 2010 at 8:15 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> Now, it may be worth considering an addition to the inspect module
> that was basically:
>
> def getattr_static(obj, attr):
> ? ?"""Retrieve attributes without triggering dynamic lookup via the
> descriptor protocol,
> ? ? ? ?__getattr__ or __getattribute__.
>
> ? ? ? ?Note: this function may not be able to retrieve all attributes
> reported by dir(obj)
> ? ?"""
> ? ?try:
> ? ? ? ?instance_dict = object.__getattribute__(obj, "__dict__")
> ? ?except AttributeError:
> ? ? ? ?pass
> ? ?else:
> ? ? ? ?if attr in instance_dict:
> ? ? ? ? ? ?return instance_dict[attr]
> ? ?for entry in getmro(obj.__class__):
> ? ? ? ?try:
> ? ? ? ? ? ?return entry.__dict__[attr]
> ? ? ? ?except AttributeError:
> ? ? ? ? ? ?pass

Second attempt with a default value parameter and correctly raising
AttributeError if not found:

_sentinel = object()
def getattr_static(obj, attr, default=_sentinel):
    """Retrieve attributes without triggering dynamic lookup via the
        descriptor protocol,  __getattr__ or __getattribute__.

        Note: this function may not be able to retrieve all attributes
        reported by dir(obj)
    """
    try:
        instance_dict = object.__getattribute__(obj, "__dict__")
    except AttributeError:
        pass
    else:
        if attr in instance_dict:
            return instance_dict[attr]
    for entry in getmro(obj.__class__):
        try:
            return entry.__dict__[attr]
        except AttributeError:
            pass
    if default is not _sentinel:
        return default
    raise AttributeError(attr)

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From ncoghlan at gmail.com  Tue Aug 24 00:15:19 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 24 Aug 2010 08:15:19 +1000
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <AANLkTiniWduAnWfmw+rV06fWAUYGNj4USce_cTOsoBgW@mail.gmail.com>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
	<2C284C09-3819-4858-A75A-34597DD668B7@gmail.com>
	<AANLkTimFeoZsRdUfWfhSyievK_819KFRoqDO2H3sc2JN@mail.gmail.com>
	<4C72D552.2030306@voidspace.org.uk>
	<AANLkTinzZ40ykb+JHFFJ9W=4ww5AwiLnd=_s5pVgqVaN@mail.gmail.com>
	<65FC8A3B-F9AF-4ED9-B63C-41335EF49E1A@gmail.com>
	<AANLkTiniuGQpt6dS4wi1yUBcBP2GZPDdStzL39T-kkFt@mail.gmail.com>
	<4C72E1F2.2020209@voidspace.org.uk>
	<AANLkTimGMunx9uEJMqDrQYLjKAOmypWQoOuACLDpWkGQ@mail.gmail.com>
	<4C72E372.5060201@voidspace.org.uk>
	<AANLkTiniWduAnWfmw+rV06fWAUYGNj4USce_cTOsoBgW@mail.gmail.com>
Message-ID: <AANLkTikSKdYRu5kJDxLT-m4Y_bM33mY+kWaBawyreTRo@mail.gmail.com>

On Tue, Aug 24, 2010 at 7:40 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> Properties are allowed to do whatever the heck they want. That doesn't mean
>> that you have to execute code to determine whether they exist or not.
>
> If you don't want to execute properties, do the lookup on the type,
> not the instance (obviously, you know the dance you need to do, since
> you've linked the code where you did it). Having apparently simple
> query operations like hasattr/getattr/len/etc execute arbitrary code
> is where much of the language's flexibility comes from, so I don't see
> how it can really be surprising when it happens.

Now, it may be worth considering an addition to the inspect module
that was basically:

def getattr_static(obj, attr):
    """Retrieve attributes without triggering dynamic lookup via the
descriptor protocol,
        __getattr__ or __getattribute__.

        Note: this function may not be able to retrieve all attributes
reported by dir(obj)
    """
    try:
        instance_dict = object.__getattribute__(obj, "__dict__")
    except AttributeError:
        pass
    else:
        if attr in instance_dict:
            return instance_dict[attr]
    for entry in getmro(obj.__class__):
        try:
            return entry.__dict__[attr]
        except AttributeError:
            pass

(not needing to deal with classic classes simplifies things a bit)

So, allowing for the fact that dir() may report attributes that can
only be found via dynamic lookup, your get_docstrings example could
become something like:

def get_docstrings(obj):
    try:
        members = dir(obj)
    except Exception:
        members = []
    for member in members:
        try:
            doc = getattr_static(obj, member).__doc__
        except AttributeError:
            doc = None
        yield member, doc

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From ncoghlan at gmail.com  Tue Aug 24 00:17:20 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 24 Aug 2010 08:17:20 +1000
Subject: [Python-Dev] 'hasattr' is broken by design
In-Reply-To: <4C72ECDC.8080104@voidspace.org.uk>
References: <E3614924-1DB6-4DCE-9976-4358CD9AA8B9@gmail.com>
	<2C284C09-3819-4858-A75A-34597DD668B7@gmail.com>
	<AANLkTimFeoZsRdUfWfhSyievK_819KFRoqDO2H3sc2JN@mail.gmail.com>
	<4C72D552.2030306@voidspace.org.uk>
	<AANLkTinzZ40ykb+JHFFJ9W=4ww5AwiLnd=_s5pVgqVaN@mail.gmail.com>
	<65FC8A3B-F9AF-4ED9-B63C-41335EF49E1A@gmail.com>
	<AANLkTiniuGQpt6dS4wi1yUBcBP2GZPDdStzL39T-kkFt@mail.gmail.com>
	<4C72E1F2.2020209@voidspace.org.uk>
	<AANLkTimGMunx9uEJMqDrQYLjKAOmypWQoOuACLDpWkGQ@mail.gmail.com>
	<4C72E372.5060201@voidspace.org.uk>
	<AANLkTiniWduAnWfmw+rV06fWAUYGNj4USce_cTOsoBgW@mail.gmail.com>
	<4C72ECDC.8080104@voidspace.org.uk>
Message-ID: <AANLkTim9Po1Db199MJ8h4tvoazpBN9rtGjZB4qC4JNmi@mail.gmail.com>

On Tue, Aug 24, 2010 at 7:49 AM, Michael Foord
<fuzzyman at voidspace.org.uk> wrote:
> Certainly that is true for len. getattr obviously involves invoking code if
> you are fetching a property or descriptor. No idea how you conclude that
> hasattr executing code adds flexibility to the language though.

Proxy objects like the one in the weakref module don't work if
hasattr() doesn't implicitly invoke __getattr__.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From tjreedy at udel.edu  Thu Aug 26 08:18:52 2010
From: tjreedy at udel.edu (Terry Reedy)
Date: Thu, 26 Aug 2010 02:18:52 -0400
Subject: [Python-Dev] Fwd: i18n
In-Reply-To: <AANLkTi=dqdZ-uVhjdBjxLqFKX-vwrMCP9e4CmHGsnyPY@mail.gmail.com>
References: <AANLkTinv=a8f3kO56CJ3FUgSZPh23fuSs7zyaofj=GMM@mail.gmail.com>	<20100814081816.GC49566@nexus.in-nomine.org>	<AANLkTinAYVWrqw2tO3DaY7rb+n8xLQgv6ri_RkxwYCJH@mail.gmail.com>	<AANLkTim62674F3w-c8gaUggco0uuwJAD_a+7b-DGrgRN@mail.gmail.com>	<AANLkTi=Ss+ZK_GnxrkaC_O-YAHMDxWHL34qVAcvAJvu1@mail.gmail.com>	<AANLkTimq5vF3WqpDZHe1W4ruYiNb1qbYFgRha8iSUEaF@mail.gmail.com>	<4C75617A.6050204@voidspace.org.uk>
	<i53u8r$fol$1@dough.gmane.org>	<AANLkTikqGiFKS7pjitKCj1yC1WOCj4NCTVzN1i8aHRss@mail.gmail.com>	<i54b25$1lo$1@dough.gmane.org>
	<AANLkTi=dqdZ-uVhjdBjxLqFKX-vwrMCP9e4CmHGsnyPY@mail.gmail.com>
Message-ID: <i5510b$tvf$1@dough.gmane.org>

On 8/25/2010 9:06 PM, Neil Hodgson wrote:
> Terry Reedy:
>
>>   File "C:\Python26\lib\socket.py", line 406, in readline
>>     data = self._sock.recv(self._rbufsize)
>> socket.error: [Errno 10054] A l?tez? kapcsolatot a t?voli ?llom?s
>> k?nyszer?tette n bez?rta
>
>     That is pretty good mojibake. One of the problems of providing
> localized error messages is that the messages may be messed up at
> different stages. The original text was
> A l?tez? kapcsolatot a t?voli ?llom?s k?nyszer?tetten bez?rta.
>     It was printed in iso8859_2 (ISO standard for Eastern European)
> then those bytes were pasted in as if they were cp852 (MS-DOS Eastern
> European).
>
> text = "A l?tez? kapcsolatot a t?voli ?llom?s k?nyszer?tetten bez?rta."
> print(str(text.encode('iso8859_2'), 'cp852'))

Which is to say that pasting the 'message' into a translator would not 
work to well ;-)
Which is to say that the original *really* should be included.

-- 
Terry Jan Reedy



From martin at v.loewis.de  Thu Aug 26 08:31:50 2010
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Thu, 26 Aug 2010 08:31:50 +0200
Subject: [Python-Dev] Fwd: i18n
In-Reply-To: <AANLkTi=dqdZ-uVhjdBjxLqFKX-vwrMCP9e4CmHGsnyPY@mail.gmail.com>
References: <AANLkTinv=a8f3kO56CJ3FUgSZPh23fuSs7zyaofj=GMM@mail.gmail.com>	<20100814081816.GC49566@nexus.in-nomine.org>	<AANLkTinAYVWrqw2tO3DaY7rb+n8xLQgv6ri_RkxwYCJH@mail.gmail.com>	<AANLkTim62674F3w-c8gaUggco0uuwJAD_a+7b-DGrgRN@mail.gmail.com>	<AANLkTi=Ss+ZK_GnxrkaC_O-YAHMDxWHL34qVAcvAJvu1@mail.gmail.com>	<AANLkTimq5vF3WqpDZHe1W4ruYiNb1qbYFgRha8iSUEaF@mail.gmail.com>	<4C75617A.6050204@voidspace.org.uk>
	<i53u8r$fol$1@dough.gmane.org>	<AANLkTikqGiFKS7pjitKCj1yC1WOCj4NCTVzN1i8aHRss@mail.gmail.com>	<i54b25$1lo$1@dough.gmane.org>
	<AANLkTi=dqdZ-uVhjdBjxLqFKX-vwrMCP9e4CmHGsnyPY@mail.gmail.com>
Message-ID: <4C760A56.4060002@v.loewis.de>

>    That is pretty good mojibake. One of the problems of providing
> localized error messages is that the messages may be messed up at
> different stages. The original text was
> A l?tez? kapcsolatot a t?voli ?llom?s k?nyszer?tetten bez?rta.
>    It was printed in iso8859_2 (ISO standard for Eastern European)
> then those bytes were pasted in as if they were cp852 (MS-DOS Eastern
> European).

That's an old Python 2.x bug. The message was probably printed in a
terminal Window, yet Python did not recode it from what Windows provided
(and indeed, it couldn't, because it couldn't know what encoding the
exception string was in when it printed it).

I believe this is fixed in Python 3, which uses a Unicode string for the
text.

Regards,
Martin

From martin at v.loewis.de  Thu Aug 26 08:36:19 2010
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Thu, 26 Aug 2010 08:36:19 +0200
Subject: [Python-Dev] Fwd: i18n
In-Reply-To: <i5510b$tvf$1@dough.gmane.org>
References: <AANLkTinv=a8f3kO56CJ3FUgSZPh23fuSs7zyaofj=GMM@mail.gmail.com>	<20100814081816.GC49566@nexus.in-nomine.org>	<AANLkTinAYVWrqw2tO3DaY7rb+n8xLQgv6ri_RkxwYCJH@mail.gmail.com>	<AANLkTim62674F3w-c8gaUggco0uuwJAD_a+7b-DGrgRN@mail.gmail.com>	<AANLkTi=Ss+ZK_GnxrkaC_O-YAHMDxWHL34qVAcvAJvu1@mail.gmail.com>	<AANLkTimq5vF3WqpDZHe1W4ruYiNb1qbYFgRha8iSUEaF@mail.gmail.com>	<4C75617A.6050204@voidspace.org.uk>	<i53u8r$fol$1@dough.gmane.org>	<AANLkTikqGiFKS7pjitKCj1yC1WOCj4NCTVzN1i8aHRss@mail.gmail.com>	<i54b25$1lo$1@dough.gmane.org>	<AANLkTi=dqdZ-uVhjdBjxLqFKX-vwrMCP9e4CmHGsnyPY@mail.gmail.com>
	<i5510b$tvf$1@dough.gmane.org>
Message-ID: <4C760B63.1080205@v.loewis.de>

Am 26.08.2010 08:18, schrieb Terry Reedy:
> On 8/25/2010 9:06 PM, Neil Hodgson wrote:
>> Terry Reedy:
>>
>>>   File "C:\Python26\lib\socket.py", line 406, in readline
>>>     data = self._sock.recv(self._rbufsize)
>>> socket.error: [Errno 10054] A l?tez? kapcsolatot a t?voli ?llom?s
>>> k?nyszer?tette n bez?rta
>>
> Which is to say that the original *really* should be included.

And indeed, the original message *was* included: [Errno 10054]
JGFI, and out comes "An existing connection was forcibly closed by the
remote host", commonly known as "Connection reset by peer".

Regards,
Martin

From martin at v.loewis.de  Thu Aug 26 08:37:02 2010
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 26 Aug 2010 08:37:02 +0200
Subject: [Python-Dev] CHM filename (was  Released: Python 2.6.6)
In-Reply-To: <AANLkTikOEBohU0PPGfJ2AGj09QoiCgcoGXx+9qYixg+3@mail.gmail.com>
References: <AANLkTim2zU_6Rx75FGUB2B5FPhy6wPDQfCPQ0q+0RPdp@mail.gmail.com>	<4C759462.1040405@v.loewis.de>
	<AANLkTikOEBohU0PPGfJ2AGj09QoiCgcoGXx+9qYixg+3@mail.gmail.com>
Message-ID: <4C760B8E.9060404@v.loewis.de>

Am 26.08.2010 01:28, schrieb Adal Chiriliuc:
> And there doesn't seem to be a link to
> download the CHM files (the last I could find on python.org is for
> Python 2.6.2).

Thanks for pointing that out; there is now.

Regards,
Martin

From ajm at flonidan.dk  Thu Aug 26 10:42:00 2010
From: ajm at flonidan.dk (Anders J. Munch)
Date: Thu, 26 Aug 2010 10:42:00 +0200
Subject: [Python-Dev] Fwd: i18n
In-Reply-To: <i53u8r$fol$1@dough.gmane.org>
References: <AANLkTinv=a8f3kO56CJ3FUgSZPh23fuSs7zyaofj=GMM@mail.gmail.com>	<20100814081816.GC49566@nexus.in-nomine.org>	<AANLkTinAYVWrqw2tO3DaY7rb+n8xLQgv6ri_RkxwYCJH@mail.gmail.com>	<AANLkTim62674F3w-c8gaUggco0uuwJAD_a+7b-DGrgRN@mail.gmail.com>	<AANLkTi=Ss+ZK_GnxrkaC_O-YAHMDxWHL34qVAcvAJvu1@mail.gmail.com>	<AANLkTimq5vF3WqpDZHe1W4ruYiNb1qbYFgRha8iSUEaF@mail.gmail.com><4C75617A.6050204@voidspace.org.uk>
	<i53u8r$fol$1@dough.gmane.org>
Message-ID: <9B1795C95533CA46A83BA1EAD4B010307007C8@flonidanmail.flonidan.net>

Terry Reedy wrote:
> Localized messages should be in addition to rather than a replacement
> for the English version. I thought we had this discussion somewhere --
> here? ideas? maybe a tracker issue?

This could be done as a free-standing library, there's no reason to
involve core CPython.  Just do message translation at a later stage,
e.g. in a custom sys.excepthook. 

I did a quick demo:
|  Python 3.2a1 (r32a1:83346, Jul 31 2010, 18:36:39) [MSC v.1500 32 bit
(Intel)] on
|   win32
|  Type "help", "copyright", "credits" or "license" for more
information.
|  >>> import localise_exceptions
|  >>> localise_exceptions.install_excepthook('DK')
|  >>> None.no_such_attr
|  Traceback (most recent call last):
|  
|    File "<stdin>", line 1, in <module>
|  
|  AttributeError: 'NoneType' objektet har ingen attribut 'no_such_attr'

localise_exceptions.py is at http://pastebin.com/QJCn8gmd

regards, Anders


From sylvain.mora at googlemail.com  Thu Aug 26 14:37:36 2010
From: sylvain.mora at googlemail.com (Sylvain Mora)
Date: Thu, 26 Aug 2010 14:37:36 +0200
Subject: [Python-Dev] Update Shell profile for ZSH on Mac OS
Message-ID: <AE735D9D-8281-473E-94AA-979ED43BCB46@gmail.com>

Hi,

I use python for more than a year now and i bought a MacBook in July. I installed Python 2.7 using the .dmg archive on the official website. After the installation I launched the Update Shell Profile.command script, but it doesn't work with ZSH. That's why I have write a small patch to be able to use this script with ZSH shell.

He simply set the path fo zsh shell.

Sorry for errors in the e-mail and the patch, but i'm french student and it is my first patch.

Hoping that it is useful for you, best regards
Sylvain

-------------- next part --------------
A non-text attachment was scrubbed...
Name: update_shell_profile.patch
Type: application/octet-stream
Size: 624 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100826/08db27dc/attachment.obj>

From yselivanov at gmail.com  Thu Aug 26 17:00:04 2010
From: yselivanov at gmail.com (Yury Selivanov)
Date: Thu, 26 Aug 2010 11:00:04 -0400
Subject: [Python-Dev] Return from generators in Python 3.2
Message-ID: <3647704A-8952-4C14-A6EF-EF70E87497F8@gmail.com>

Hello,

I want to bring up a "forbidden" topic, however, I believe I have some strong points.

There are many ways of doing asynchronous programming in Python.  Multiprocessing, 
Threads, Greenlets, Deferred Object (Callbacks) and Coroutines.  The latter is quite 
a new approach, but it gets more and more attention.  What's really fascinating about 
coroutines, is that a code flow of a program using them reads naturally and straight.  
Callbacks break that code flow making it much harder to read and understand, threads 
don't work good in Python, and greenlets... greenlets  are too magical, and,
potentially, harmful.

So, coroutines are good, and that is proved by a pleiad of new frameworks that utilize
them: Monocle, cogen, and many others. However, coroutines in python are a bit 
incomplete.  There is no standard way of returning a result value, making coroutine
stop.

Let's take a look at the following example:

... @bus.method
... def method1():
...		# some computation
...		return result
...
... @bus.method
... def method2():
...		data = yield memcache.get(...)
...     # some computation
...
...     # and now, the most interesting point. Time to return a result. 
...		# Pick the prettiest line:
...		#      
...		# yield Return(result)
...		# return_ (result)
...		# raise StopIteration(result)

As you can see, there is no way of simple abstraction of coroutines.  How nice is
the 'yield' syntax here, that clearly marks async call, and how ugly is the return 
code.  Speaking about large amounts of a code like the above it's hard to maintain 
and refactor it.  Adding one yield statement to some generically decorated handler 
will force you to fix all returns and vice versa.  Moreover, lack of proper return 
protocol complicates the underlying code.

The very straightforward solution was proposed in PEP 380, and  here it is a good 
place to say, that PEP 380 is not all about returns.  It's all about new 'yield from' 
statement, and the new return syntax for coroutine is the very small part of it.
However, in any currently existing framework it is possible to implement 'yield from' 
statement (with smth like yield From(...)), but there's absolutely no  way to correct 
the return problem, as it raises SyntaxError which is impossible to catch.  Therefore, 
I think that we can consider the returns problem apart from PEP 380.

Proposed change uses the same type of approach as was introduced in PEP 380, but in
a slightly different way.  Instead of attaching the return value to StopIteration
exception, we can introduce another one, let's call it GeneratorReturn (derived from
BaseException).  Still easy to use it in frameworks, but make it impossible to break
things unintentionally.  For example, it will protect us from cases like the 
following:

... def test():
...		for i in range(10):
...			yield i
...		return 10

In the above, GeneratorReturn error will be propagated stopping the program execution.
Strictly speaking, the proposed change is just alters the current Python behaviour,
making the 'return value' statement raise catchable error (instead of SyntaxError.)

Speaking about PEP 3003.  I'm pretty much sure that the idea behind moratorium on
serious language changes was to give alternative python interpreters a chance to
catch up Python 3.  Well, the proposed is a very small change in CPython, just few
lines of code.  It doesn't change grammar or AST tree structure, and it is fully
backwards compatible.  I've looked at the PyPy code and found that the change is 
*very* easy to port there, and I'm certain that the situation is the same for Jython 
and IronPython.  (If this new feature would be the only problem why we don't see
Jython or PyPy supporting 3.2 version we all would be more than happy.)  Given all
that, I think PEP 3003 is inapplicable to this proposal.


Pros:
 - The change on the interpreter side is tiny (reducing the entropy in symtable.c!)
 - No affect on grammar or AST structure.
 - Easy to port to other interpreters.
 - Fully backward compatible.
 - On the very basic level it will change current behaviour from raising an 
   uncatchable error to raising a catchable one.  Nobody will be confused.
 - Another key feature of Python 3, that will probably encourage people to
   migrate.
 - Will make coroutines more attractive and stimulate the rise of new frameworks
   and development of new ones.
 - One way of doing things.  The same interface in frameworks, code in coroutines
   look almost the same as in subroutines but with yields.  Make coroutines protocol
   complete.


If we decide to postpone this feature till Python 3.3, than we'll push it all back
for *years*.  The change is tiny, but it means really a lot. Those who tried to 
work with coroutines will understand me.  Let's at least consider it.


PS I'm attaching a patch to the letter; it's far from ideal state, but contains the
GeneratorReturn exception, code to raise it and the corresponding unittests.


-
Yury

-------------- next part --------------
A non-text attachment was scrubbed...
Name: generators_return.patch
Type: application/octet-stream
Size: 7179 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100826/a11f5933/attachment.obj>

From scott+python-dev at scottdial.com  Thu Aug 26 18:20:15 2010
From: scott+python-dev at scottdial.com (Scott Dial)
Date: Thu, 26 Aug 2010 12:20:15 -0400
Subject: [Python-Dev] Return from generators in Python 3.2
In-Reply-To: <3647704A-8952-4C14-A6EF-EF70E87497F8@gmail.com>
References: <3647704A-8952-4C14-A6EF-EF70E87497F8@gmail.com>
Message-ID: <4C76943F.7040509@scottdial.com>

On 8/26/2010 11:00 AM, Yury Selivanov wrote:
> If we decide to postpone this feature till Python 3.3, than we'll push it all back
> The change is tiny, but it means really a lot.

AFAICT, this change was the most controversial part of PEP 380.

> PS I'm attaching a patch to the letter; it's far from ideal state, but contains the
> GeneratorReturn exception, code to raise it and the corresponding unittests.

I believe overloading StopIteration for this purpose was considered more
acceptable than creating a new exception. BTW, attaching patches to
emails on this list is generally the best way to have few look at your
patch. :-p Also, this seems more appropriate for python-ideas.

-- 
Scott Dial
scott at scottdial.com
scodial at cs.indiana.edu

From yselivanov at gmail.com  Thu Aug 26 18:48:59 2010
From: yselivanov at gmail.com (Yury Selivanov)
Date: Thu, 26 Aug 2010 12:48:59 -0400
Subject: [Python-Dev] Return from generators in Python 3.2
In-Reply-To: <4C76943F.7040509@scottdial.com>
References: <3647704A-8952-4C14-A6EF-EF70E87497F8@gmail.com>
	<4C76943F.7040509@scottdial.com>
Message-ID: <BEC898AE-BCD9-4399-B5B4-81D264500436@gmail.com>

On 2010-08-26, at 12:20 PM, Scott Dial wrote:

> On 8/26/2010 11:00 AM, Yury Selivanov wrote:
>> If we decide to postpone this feature till Python 3.3, than we'll push it all back
>> The change is tiny, but it means really a lot.
> 
> AFAICT, this change was the most controversial part of PEP 380.
> 
>> PS I'm attaching a patch to the letter; it's far from ideal state, but contains the
>> GeneratorReturn exception, code to raise it and the corresponding unittests.
> 
> I believe overloading StopIteration for this purpose was considered more
> acceptable than creating a new exception.

Whatever the Python community decides.  I was trying to make several points
regarding the problem, and proposed a solution which in my opinion is slightly
better than one described in the pep.

> BTW, attaching patches to
> emails on this list is generally the best way to have few look at your
> patch. :-p

Hm, my mailing client clearly indicates that the patch has been attached and sent.
In any case, here is a direct link: http://dl.dropbox.com/u/21052/generators_return.patch

-
Yury

From brett at python.org  Thu Aug 26 23:20:33 2010
From: brett at python.org (Brett Cannon)
Date: Thu, 26 Aug 2010 14:20:33 -0700
Subject: [Python-Dev] Update Shell profile for ZSH on Mac OS
In-Reply-To: <AE735D9D-8281-473E-94AA-979ED43BCB46@gmail.com>
References: <AE735D9D-8281-473E-94AA-979ED43BCB46@gmail.com>
Message-ID: <AANLkTi=07i-4UpbUx4rrcP+pOUp1_Y3KftWye4xvjFJe@mail.gmail.com>

If you could, Sylvain, please post the patch to bugs.python.org. That
way it doesn't get lost amongst the emails sent to python-dev.

-Brett

On Thu, Aug 26, 2010 at 05:37, Sylvain Mora <sylvain.mora at googlemail.com> wrote:
> Hi,
>
> I use python for more than a year now and i bought a MacBook in July. I installed Python 2.7 using the .dmg archive on the official website. After the installation I launched the Update Shell Profile.command script, but it doesn't work with ZSH. That's why I have write a small patch to be able to use this script with ZSH shell.
>
> He simply set the path fo zsh shell.
>
> Sorry for errors in the e-mail and the patch, but i'm french student and it is my first patch.
>
> Hoping that it is useful for you, best regards
> Sylvain
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/brett%40python.org
>
>

From ncoghlan at gmail.com  Fri Aug 27 00:11:46 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 27 Aug 2010 08:11:46 +1000
Subject: [Python-Dev] Return from generators in Python 3.2
In-Reply-To: <3647704A-8952-4C14-A6EF-EF70E87497F8@gmail.com>
References: <3647704A-8952-4C14-A6EF-EF70E87497F8@gmail.com>
Message-ID: <AANLkTimfKiNmeH5o6L73bELGSBPoJD7F_=2nZ0Xor4iD@mail.gmail.com>

On Fri, Aug 27, 2010 at 1:00 AM, Yury Selivanov <yselivanov at gmail.com> wrote:
> In the above, GeneratorReturn error will be propagated stopping the program execution.
> Strictly speaking, the proposed change is just alters the current Python behaviour,
> making the 'return value' statement raise catchable error (instead of SyntaxError.)

There are fairly extensive discussions of using a new GeneratorReturn
exception rather than StopIteration in the python-dev archives. As I
recall, one key factor leading to the use of StopIteration was the
suggestion's implied breakage of the equivalence between "return"
(which would continue to raise StopIteration) and "return None" (which
would raise GeneratorReturn with a value of None). Using a different
exception also made all generator handling code clumsier, since it now
needed to deal with two exceptions rather than just one.

Since the only situations where a return value could be inadvertently
ignored were those where the application clearly didn't care about the
return value anyway, it was decided that sticking with a single
exception type was the better approach.

PEP 380 should probably mention this idea explicitly though, since
using a new exception type is a fairly obvious alternative suggestion
and the discussion of the idea is scattered all over the place in the
archives.

As for breaking the moratorium for it - no, not even close to a big
enough win, since people can already write "raise
CoroutineReturn(result)".

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From yselivanov at gmail.com  Fri Aug 27 00:31:52 2010
From: yselivanov at gmail.com (Yury Selivanov)
Date: Thu, 26 Aug 2010 18:31:52 -0400
Subject: [Python-Dev] Return from generators in Python 3.2
In-Reply-To: <AANLkTimfKiNmeH5o6L73bELGSBPoJD7F_=2nZ0Xor4iD@mail.gmail.com>
References: <3647704A-8952-4C14-A6EF-EF70E87497F8@gmail.com>
	<AANLkTimfKiNmeH5o6L73bELGSBPoJD7F_=2nZ0Xor4iD@mail.gmail.com>
Message-ID: <46470DFD-4205-4FF0-8384-20DD4690FF58@gmail.com>

On 2010-08-26, at 6:11 PM, Nick Coghlan wrote:

> On Fri, Aug 27, 2010 at 1:00 AM, Yury Selivanov <yselivanov at gmail.com> wrote:
>> In the above, GeneratorReturn error will be propagated stopping the program execution.
>> Strictly speaking, the proposed change is just alters the current Python behaviour,
>> making the 'return value' statement raise catchable error (instead of SyntaxError.)
> 
> There are fairly extensive discussions of using a new GeneratorReturn
> exception rather than StopIteration in the python-dev archives. As I
> recall, one key factor leading to the use of StopIteration was the
> suggestion's implied breakage of the equivalence between "return"
> (which would continue to raise StopIteration) and "return None" (which
> would raise GeneratorReturn with a value of None). Using a different
> exception also made all generator handling code clumsier, since it now
> needed to deal with two exceptions rather than just one.

Yes, I understand the point of having two different exceptions for 
basically two close related things - 'return None' and 'return value'.

However, as I outlined in the first message, this was intended to prevent
this kind of mistakes:

... def test():
...     for i in range(10):
...         yield i
...     return 10

Which will certainly happen, especially with people new to python.

Again, this exception will be used in very specific places by a very 
specific software, that expects it.  Otherwise, it should be propagated
and crash the whole thing.

As for the generator handling code -- are you sure there is that much 
of it?

> Since the only situations where a return value could be inadvertently
> ignored were those where the application clearly didn't care about the
> return value anyway, it was decided that sticking with a single
> exception type was the better approach.

Good point.  It's all about our level of care about beginners ;)

> PEP 380 should probably mention this idea explicitly though, since
> using a new exception type is a fairly obvious alternative suggestion
> and the discussion of the idea is scattered all over the place in the
> archives.
> 
> As for breaking the moratorium for it - no, not even close to a big
> enough win, since people can already write "raise
> CoroutineReturn(result)".

Well, people certainly can.  But the goal is to make convenient instruments
for everyday use.  I, for example, deal with really a lot of coroutine based
code, and it's very annoying that I have to use some creepy abstractions
in order to just return a value!  It's especially annoying when you have
normal code with normal returns and coroutines, with 'return_ (value)'. 
And I don't think it frustrates just me.  Coroutines protocol is incomplete
and there is a very little action required to fix it.

All this proposal is suggesting is to replace SyntaxError with 
GeneratorReturn (or StopIteration).  I'd classify is as a minor change
than some special refactoring that may fall under the moratorium.  Correct
me if I'm wrong.

-
Yury

From sylvain.mora at googlemail.com  Fri Aug 27 00:40:40 2010
From: sylvain.mora at googlemail.com (Sylvain Mora)
Date: Fri, 27 Aug 2010 00:40:40 +0200
Subject: [Python-Dev] Update Shell profile for ZSH on Mac OS
In-Reply-To: <AANLkTi=07i-4UpbUx4rrcP+pOUp1_Y3KftWye4xvjFJe@mail.gmail.com>
References: <AE735D9D-8281-473E-94AA-979ED43BCB46@gmail.com>
	<AANLkTi=07i-4UpbUx4rrcP+pOUp1_Y3KftWye4xvjFJe@mail.gmail.com>
Message-ID: <9AC9CB04-D934-4AC1-B32C-87C5C83C4076@gmail.com>


Le 26 ao?t 2010 ? 23:20, Brett Cannon a ?crit :

> If you could, Sylvain, please post the patch to bugs.python.org. That
> way it doesn't get lost amongst the emails sent to python-dev.
> 
> -Brett

Hi,

Thank you for you answer. I will post the patch to bugs.python.org.

Regards,
Sylvain


From ncoghlan at gmail.com  Fri Aug 27 00:42:42 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 27 Aug 2010 08:42:42 +1000
Subject: [Python-Dev] Return from generators in Python 3.2
In-Reply-To: <46470DFD-4205-4FF0-8384-20DD4690FF58@gmail.com>
References: <3647704A-8952-4C14-A6EF-EF70E87497F8@gmail.com>
	<AANLkTimfKiNmeH5o6L73bELGSBPoJD7F_=2nZ0Xor4iD@mail.gmail.com>
	<46470DFD-4205-4FF0-8384-20DD4690FF58@gmail.com>
Message-ID: <AANLkTimQnHUymPRM8-aeGm40f5YRkhzMjYi4F7oKMKv_@mail.gmail.com>

On Fri, Aug 27, 2010 at 8:31 AM, Yury Selivanov <yselivanov at gmail.com> wrote:
> All this proposal is suggesting is to replace SyntaxError with
> GeneratorReturn (or StopIteration). ?I'd classify is as a minor change
> than some special refactoring that may fall under the moratorium. ?Correct
> me if I'm wrong.

It's either a new builtin or affects the API of an existing builtin,
and it is moving something from a compile time error to a runtime
error. Things that fall under the moratorium aren't "special
refactorings" - they're anything that affects the builtins or the
language syntax, so trying to separate out this one part of PEP 380
fails on both counts.

Coroutine programmers have lived with the status quo for years
already, putting up with it for a couple more until PEP 380 goes in
isn't going to hurt them all that much.

On the GeneratorReturn vs StopIteration front, adding a new builtin
exception is a big deal. "Newbie programmers might not notice that
their return statement isn't doing anything" isn't a particularly good
justification for adding one.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From sylvain.mora at googlemail.com  Fri Aug 27 01:29:01 2010
From: sylvain.mora at googlemail.com (Sylvain Mora)
Date: Fri, 27 Aug 2010 01:29:01 +0200
Subject: [Python-Dev] Update Shell profile for ZSH on Mac OS
In-Reply-To: <9AC9CB04-D934-4AC1-B32C-87C5C83C4076@gmail.com>
References: <AE735D9D-8281-473E-94AA-979ED43BCB46@gmail.com>
	<AANLkTi=07i-4UpbUx4rrcP+pOUp1_Y3KftWye4xvjFJe@mail.gmail.com>
	<9AC9CB04-D934-4AC1-B32C-87C5C83C4076@gmail.com>
Message-ID: <1F312497-C55F-4E0B-BD58-1C249416F714@gmail.com>

Hi,

Is it possible to know the name of the macos package maintainer ?

Regards,
Sylvain

Le 27 ao?t 2010 ? 00:40, Sylvain Mora a ?crit :

> 
> Le 26 ao?t 2010 ? 23:20, Brett Cannon a ?crit :
> 
>> If you could, Sylvain, please post the patch to bugs.python.org. That
>> way it doesn't get lost amongst the emails sent to python-dev.
>> 
>> -Brett
> 
> Hi,
> 
> Thank you for you answer. I will post the patch to bugs.python.org.
> 
> Regards,
> Sylvain
> 


From greg.ewing at canterbury.ac.nz  Fri Aug 27 02:04:42 2010
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Fri, 27 Aug 2010 12:04:42 +1200
Subject: [Python-Dev] Return from generators in Python 3.2
In-Reply-To: <46470DFD-4205-4FF0-8384-20DD4690FF58@gmail.com>
References: <3647704A-8952-4C14-A6EF-EF70E87497F8@gmail.com>
	<AANLkTimfKiNmeH5o6L73bELGSBPoJD7F_=2nZ0Xor4iD@mail.gmail.com>
	<46470DFD-4205-4FF0-8384-20DD4690FF58@gmail.com>
Message-ID: <4C77011A.7070107@canterbury.ac.nz>

Yury Selivanov wrote:

> However, as I outlined in the first message, this was intended to prevent
> this kind of mistakes:
> 
> ... def test():
> ...     for i in range(10):
> ...         yield i
> ...     return 10
> 
> Which will certainly happen, especially with people new to python.

That very problem was considered in the discussion, and
it was concluded that it wasn't severe enough to be worth
breaking the symmetry between return <-> StopIteration and
return value <-> StopIteration(value).

> Good point.  It's all about our level of care about beginners ;)

While due consideration is always given to beginners, being
beginner-friendly is not a good enough reason to introduce
a feature that would be *unfriendly* to experienced programmers.

> I, for example, deal with really a lot of coroutine based
> code, and it's very annoying that I have to use some creepy abstractions
> in order to just return a value!

Even with your proposal, you'd still have to use a 'creepy
abstraction' every time one of your coroutines calls another.
That's why PEP 380 deals with 'more than just return'.

-- 
Greg

From yselivanov at gmail.com  Fri Aug 27 02:05:52 2010
From: yselivanov at gmail.com (Yury Selivanov)
Date: Thu, 26 Aug 2010 20:05:52 -0400
Subject: [Python-Dev] Return from generators in Python 3.2
In-Reply-To: <4C77011A.7070107@canterbury.ac.nz>
References: <3647704A-8952-4C14-A6EF-EF70E87497F8@gmail.com>
	<AANLkTimfKiNmeH5o6L73bELGSBPoJD7F_=2nZ0Xor4iD@mail.gmail.com>
	<46470DFD-4205-4FF0-8384-20DD4690FF58@gmail.com>
	<4C77011A.7070107@canterbury.ac.nz>
Message-ID: <5F6D8E70-1652-4F4B-B10D-69327623700C@gmail.com>

On 2010-08-26, at 8:04 PM, Greg Ewing wrote:
> Even with your proposal, you'd still have to use a 'creepy
> abstraction' every time one of your coroutines calls another.
> That's why PEP 380 deals with 'more than just return'.

Nope.  In almost any coroutine framework you have a scheduler
or trampoline object that basically does all the work of calling,
passing values and propagating exceptions.  And many other things
that 'yield from' won't help you with (cooperation, deferring to
process/thread pools, pausing, etc.)  Being a developer of one
of such frameworks, I can tell you, that I can easily live without
'yield from', but dealing with weird return syntax is a pain.

Especially when you use decorators like @bus.method, or 
@protocol.handler, that transparently wrap your callable be it
generator or regular function.  And after that you have to use
different return syntax for them.

-
Yury

From guido at python.org  Fri Aug 27 02:25:51 2010
From: guido at python.org (Guido van Rossum)
Date: Thu, 26 Aug 2010 17:25:51 -0700
Subject: [Python-Dev] Return from generators in Python 3.2
In-Reply-To: <5F6D8E70-1652-4F4B-B10D-69327623700C@gmail.com>
References: <3647704A-8952-4C14-A6EF-EF70E87497F8@gmail.com>
	<AANLkTimfKiNmeH5o6L73bELGSBPoJD7F_=2nZ0Xor4iD@mail.gmail.com>
	<46470DFD-4205-4FF0-8384-20DD4690FF58@gmail.com>
	<4C77011A.7070107@canterbury.ac.nz>
	<5F6D8E70-1652-4F4B-B10D-69327623700C@gmail.com>
Message-ID: <AANLkTik8WnYHBzJGpPqJ+yvKHLU34kJRo4eduMCm5053@mail.gmail.com>

On Thu, Aug 26, 2010 at 5:05 PM, Yury Selivanov <yselivanov at gmail.com> wrote:
> On 2010-08-26, at 8:04 PM, Greg Ewing wrote:
>> Even with your proposal, you'd still have to use a 'creepy
>> abstraction' every time one of your coroutines calls another.
>> That's why PEP 380 deals with 'more than just return'.
>
> Nope. ?In almost any coroutine framework you have a scheduler
> or trampoline object that basically does all the work of calling,
> passing values and propagating exceptions. ?And many other things
> that 'yield from' won't help you with (cooperation, deferring to
> process/thread pools, pausing, etc.) ?Being a developer of one
> of such frameworks, I can tell you, that I can easily live without
> 'yield from', but dealing with weird return syntax is a pain.

That's not my experience. I wrote a trampoline myself (not released
yet), and found that I had to write a lot more code to deal with the
absence of yield-from than to deal with returns. In my framework,
users write 'raise Return(value)' where Return is a subclass of
StopIteration. The trampoline code that must be written to deal with
StopIteration can be extended trivially to deal with this. The only
reason I chose to use a subclass is so that I can diagnose when the
return value is not used, but I could have chosen to ignore this or
just diagnose whenever the argument to StopIteration is not None.

> Especially when you use decorators like @bus.method, or
> @protocol.handler, that transparently wrap your callable be it
> generator or regular function. ?And after that you have to use
> different return syntax for them.

Until PEP 380 is implemented, you have to use different return syntax
in generators. You have some choices: raise StopIteration(value),
raise SomethingElse(value), or callSomeFunction(value) -- where
callSomeFunction raises the exception. I like the raise variants
because they signal to tools that the flow control stops here -- e.g.
in Emacs, python-mode.el automatically dedents after a 'raise' or
'return' but not after a call (of course).

-- 
--Guido van Rossum (python.org/~guido)

From merwok at netwok.org  Fri Aug 27 03:07:05 2010
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Fri, 27 Aug 2010 03:07:05 +0200
Subject: [Python-Dev] Update Shell profile for ZSH on Mac OS
In-Reply-To: <AE735D9D-8281-473E-94AA-979ED43BCB46@gmail.com>
References: <AE735D9D-8281-473E-94AA-979ED43BCB46@gmail.com>
Message-ID: <4C770FB9.4000305@netwok.org>

Hi Sylvain

> Sorry for errors in the e-mail and the patch, but i'm french student

Being polite or cautious is a good thing in Internet communication, but
you don?t have to apologize about that. Everyone tries to express
themselves as clearly as possible, but nobody is judged because of
language. When someone makes a patch with a typo, the right reaction is
to say ?thank you? and to fix the typo.

More information: http://ostatic.com/blog/more-bad-english-please

> and it is my first patch.

We?ve all been there, don?t worry. We won?t bite, even if people may
appear abrupt in such technical discussion (well, there are also real
flamefests for some sensitive topics :).

Thank you for your contribution.

Regards


From nad at acm.org  Fri Aug 27 03:36:20 2010
From: nad at acm.org (Ned Deily)
Date: Thu, 26 Aug 2010 18:36:20 -0700
Subject: [Python-Dev] Update Shell profile for ZSH on Mac OS
References: <AE735D9D-8281-473E-94AA-979ED43BCB46@gmail.com>
	<AANLkTi=07i-4UpbUx4rrcP+pOUp1_Y3KftWye4xvjFJe@mail.gmail.com>
	<9AC9CB04-D934-4AC1-B32C-87C5C83C4076@gmail.com>
	<1F312497-C55F-4E0B-BD58-1C249416F714@gmail.com>
Message-ID: <nad-702417.18362026082010@news.gmane.org>

In article <1F312497-C55F-4E0B-BD58-1C249416F714 at gmail.com>,
 Sylvain Mora <sylvain.mora at googlemail.com> wrote:
> Is it possible to know the name of the macos package maintainer ?

Ronald Oussoren.  If you select Components -> Macintosh in the bug 
tracker when opening a new bug it will be assigned automatically; if 
not, someone will see it and update appropriately.

-- 
 Ned Deily,
 nad at acm.org


From eric at trueblade.com  Thu Aug 26 19:10:50 2010
From: eric at trueblade.com (Eric Smith)
Date: Thu, 26 Aug 2010 13:10:50 -0400
Subject: [Python-Dev] Return from generators in Python 3.2
In-Reply-To: <BEC898AE-BCD9-4399-B5B4-81D264500436@gmail.com>
References: <3647704A-8952-4C14-A6EF-EF70E87497F8@gmail.com>	<4C76943F.7040509@scottdial.com>
	<BEC898AE-BCD9-4399-B5B4-81D264500436@gmail.com>
Message-ID: <4C76A01A.5060105@trueblade.com>

On 8/26/10 12:48 PM, Yury Selivanov wrote:
> On 2010-08-26, at 12:20 PM, Scott Dial wrote:
>> BTW, attaching patches to
>> emails on this list is generally the best way to have few look at your
>> patch. :-p
>
> Hm, my mailing client clearly indicates that the patch has been attached and sent.
> In any case, here is a direct link: http://dl.dropbox.com/u/21052/generators_return.patch

I think Scott means that you should open an issue and attach the patch 
there. At least then people can find it.

-- 
Eric.

From yselivanov at gmail.com  Fri Aug 27 04:40:33 2010
From: yselivanov at gmail.com (Yury Selivanov)
Date: Thu, 26 Aug 2010 22:40:33 -0400
Subject: [Python-Dev] Return from generators in Python 3.2
In-Reply-To: <AANLkTik8WnYHBzJGpPqJ+yvKHLU34kJRo4eduMCm5053@mail.gmail.com>
References: <3647704A-8952-4C14-A6EF-EF70E87497F8@gmail.com>
	<AANLkTimfKiNmeH5o6L73bELGSBPoJD7F_=2nZ0Xor4iD@mail.gmail.com>
	<46470DFD-4205-4FF0-8384-20DD4690FF58@gmail.com>
	<4C77011A.7070107@canterbury.ac.nz>
	<5F6D8E70-1652-4F4B-B10D-69327623700C@gmail.com>
	<AANLkTik8WnYHBzJGpPqJ+yvKHLU34kJRo4eduMCm5053@mail.gmail.com>
Message-ID: <114B8495-8BDF-4916-8C1F-4C99413D7C57@gmail.com>

On 2010-08-26, at 8:25 PM, Guido van Rossum wrote:

> On Thu, Aug 26, 2010 at 5:05 PM, Yury Selivanov <yselivanov at gmail.com> wrote:
>> On 2010-08-26, at 8:04 PM, Greg Ewing wrote:
>>> Even with your proposal, you'd still have to use a 'creepy
>>> abstraction' every time one of your coroutines calls another.
>>> That's why PEP 380 deals with 'more than just return'.
>> 
>> Nope.  In almost any coroutine framework you have a scheduler
>> or trampoline object that basically does all the work of calling,
>> passing values and propagating exceptions.  And many other things
>> that 'yield from' won't help you with (cooperation, deferring to
>> process/thread pools, pausing, etc.)  Being a developer of one
>> of such frameworks, I can tell you, that I can easily live without
>> 'yield from', but dealing with weird return syntax is a pain.
> 
> That's not my experience. I wrote a trampoline myself (not released
> yet), and found that I had to write a lot more code to deal with the
> absence of yield-from than to deal with returns. In my framework,
> users write 'raise Return(value)' where Return is a subclass of
> StopIteration. The trampoline code that must be written to deal with
> StopIteration can be extended trivially to deal with this. The only
> reason I chose to use a subclass is so that I can diagnose when the
> return value is not used, but I could have chosen to ignore this or
> just diagnose whenever the argument to StopIteration is not None.

In the framework I'm talking about (not yet released too, but I do plan
to open source it one day), everything that can be yielded is an
instance of a special class - Command.  Generators are wrapped with a 
subclass of Command - Task, socket methods return Recv & Send commands
etc.  Regular python functions, by the way, can be also wrapped in a 
Task command, - the framework is smart enough to manage them automatically.
Of course, wrapping of python functions is abstracted in decorators,
so be it a simple @coroutine, or some asynchronous @bus.method - they
all are native objects to the scheduler.  And all the work of exception
propagation, IO waiting, managing of timeouts and much more is a business
framework (without 'yield from'.)

Hence the yield statement is nothing more than a point of a code flow where 
some command is pushed to the scheduler for execution.  And can be inserted
almost everywhere.

This approach differs from the one you showed in PEP 342; it's much more
complicated, but is has its own strong advantages.  It is not new though,
for instance, almost the same idea is utilized in 'cogen' framework, and
few others (can't remember all names but I did quite a big research before
writing a single line of code.)  All those frameworks are suffer from the
inability of using native return statement in generators.

Now, imagine a big project.  I mean really big complicated system, with
tens of thousands lines of code.  Code is broken down to small methods:
some of them implement some asynchronous methods on a message bus, 
some of them are mapped to serve responses on specific URLs and so on.
In the way of writing code I'm talking about, there is no distinction
between coroutines and subroutines.  There are some methods which just
return some value; some that query a potentially blocking code with 
'yield' keyword and after that they return the result - it all doesn't
matter.  Abstraction is very good and simple, 'yield' statement just marks
suspension points, and thats all.  BUT - there is a 'return problem',
so if the code got a new yield statement - you have to go and fix all 
returns and vice versa.  It just *breaks the beauty* of the language.
I've invested tons of time into it, and suffer from the weird syntax that
differs from one line to another.

Of course I can live with that, and people that developed other frameworks
will too.  But considering that the 'return' syntax is almost approved (1);
almost one hundred percent it will be merged to 3.3 (2); the change is small
and backwards compatible (3); one-two hours of work to port to other 
interpreters - so not contradict 100% with the moratorium ideas (4)  
- I've decided to bring this topic up.

The asynchronous programming is booming now.  It gets more and more 
attention day by day.  And python has a unique combination of features
that may make it one of the leaders in the field (nodejs is amateur;
erlang is hard; java, ruby and family lacks 'yield' statement so you
have to use callbacks - and that's ugly.)  Wait for this simple
feature for several years in a world that is changing that fast?
I'm not sure.

Probably the last point - this would be one more good advantage of py3k 
for python 2.x users.

Sorry for such a long text, I just wanted to make my points clear and 
provide some examples.

>> Especially when you use decorators like @bus.method, or
>> @protocol.handler, that transparently wrap your callable be it
>> generator or regular function.  And after that you have to use
>> different return syntax for them.
> 
> Until PEP 380 is implemented, you have to use different return syntax
> in generators. You have some choices: raise StopIteration(value),
> raise SomethingElse(value), or callSomeFunction(value) -- where
> callSomeFunction raises the exception. I like the raise variants
> because they signal to tools that the flow control stops here -- e.g.
> in Emacs, python-mode.el automatically dedents after a 'raise' or
> 'return' but not after a call (of course).

I'm not asking for the whole PEP380, but for a small subset of it.  So if
it's not that much contradicts with moratorium - let's discuss the feature.
If it is - then OK, I stop spamming ;-)

-
Yury

From yselivanov at gmail.com  Fri Aug 27 04:47:01 2010
From: yselivanov at gmail.com (Yury Selivanov)
Date: Thu, 26 Aug 2010 22:47:01 -0400
Subject: [Python-Dev] Return from generators in Python 3.2
In-Reply-To: <4C76A01A.5060105@trueblade.com>
References: <3647704A-8952-4C14-A6EF-EF70E87497F8@gmail.com>	<4C76943F.7040509@scottdial.com>
	<BEC898AE-BCD9-4399-B5B4-81D264500436@gmail.com>
	<4C76A01A.5060105@trueblade.com>
Message-ID: <EEFB6CAB-6B4B-4409-BFF2-1E0E88402FD4@gmail.com>

On 2010-08-26, at 1:10 PM, Eric Smith wrote:

> On 8/26/10 12:48 PM, Yury Selivanov wrote:
>> On 2010-08-26, at 12:20 PM, Scott Dial wrote:
>>> BTW, attaching patches to
>>> emails on this list is generally the best way to have few look at your
>>> patch. :-p
>> 
>> Hm, my mailing client clearly indicates that the patch has been attached and sent.
>> In any case, here is a direct link: http://dl.dropbox.com/u/21052/generators_return.patch
> 
> I think Scott means that you should open an issue and attach the patch there. At least then people can find it.

Thank you Eric, I've already done that.  Will know next time ;-)

-
Yury

From bob at redivi.com  Fri Aug 27 04:54:57 2010
From: bob at redivi.com (Bob Ippolito)
Date: Fri, 27 Aug 2010 10:54:57 +0800
Subject: [Python-Dev] Return from generators in Python 3.2
In-Reply-To: <AANLkTik8WnYHBzJGpPqJ+yvKHLU34kJRo4eduMCm5053@mail.gmail.com>
References: <3647704A-8952-4C14-A6EF-EF70E87497F8@gmail.com>
	<AANLkTimfKiNmeH5o6L73bELGSBPoJD7F_=2nZ0Xor4iD@mail.gmail.com>
	<46470DFD-4205-4FF0-8384-20DD4690FF58@gmail.com>
	<4C77011A.7070107@canterbury.ac.nz>
	<5F6D8E70-1652-4F4B-B10D-69327623700C@gmail.com>
	<AANLkTik8WnYHBzJGpPqJ+yvKHLU34kJRo4eduMCm5053@mail.gmail.com>
Message-ID: <AANLkTimiJ0f04sUMxrztW1vxpjvAW1AnZ_jwtNRydJ-0@mail.gmail.com>

On Fri, Aug 27, 2010 at 8:25 AM, Guido van Rossum <guido at python.org> wrote:
> On Thu, Aug 26, 2010 at 5:05 PM, Yury Selivanov <yselivanov at gmail.com> wrote:
>> On 2010-08-26, at 8:04 PM, Greg Ewing wrote:
>>> Even with your proposal, you'd still have to use a 'creepy
>>> abstraction' every time one of your coroutines calls another.
>>> That's why PEP 380 deals with 'more than just return'.
>>
>> Nope. ?In almost any coroutine framework you have a scheduler
>> or trampoline object that basically does all the work of calling,
>> passing values and propagating exceptions. ?And many other things
>> that 'yield from' won't help you with (cooperation, deferring to
>> process/thread pools, pausing, etc.) ?Being a developer of one
>> of such frameworks, I can tell you, that I can easily live without
>> 'yield from', but dealing with weird return syntax is a pain.
>
> That's not my experience. I wrote a trampoline myself (not released
> yet), and found that I had to write a lot more code to deal with the
> absence of yield-from than to deal with returns. In my framework,
> users write 'raise Return(value)' where Return is a subclass of
> StopIteration. The trampoline code that must be written to deal with
> StopIteration can be extended trivially to deal with this. The only
> reason I chose to use a subclass is so that I can diagnose when the
> return value is not used, but I could have chosen to ignore this or
> just diagnose whenever the argument to StopIteration is not None.

A bit off-topic, but...

In my experience the lack of "yield from" makes certain styles of
programming both very tedious and very costly for performance. One
example would be Genshi, which implements something like pipes or
filters. There are many filters that will do something once (e.g.
insert a doctype) and but have O(N) performance because of the
function call overhead of "for x in other_generator: yield x". Nest
this a few times and you'll have 10 function calls for every byte of
output (not an exaggeration in the case of Trac templates). I think if
implemented properly "yield from" could get rid of most of that
overhead.

-bob

From rrr at ronadam.com  Fri Aug 27 07:42:22 2010
From: rrr at ronadam.com (Ron Adam)
Date: Fri, 27 Aug 2010 00:42:22 -0500
Subject: [Python-Dev] Return from generators in Python 3.2
In-Reply-To: <AANLkTik8WnYHBzJGpPqJ+yvKHLU34kJRo4eduMCm5053@mail.gmail.com>
References: <3647704A-8952-4C14-A6EF-EF70E87497F8@gmail.com>	<AANLkTimfKiNmeH5o6L73bELGSBPoJD7F_=2nZ0Xor4iD@mail.gmail.com>	<46470DFD-4205-4FF0-8384-20DD4690FF58@gmail.com>	<4C77011A.7070107@canterbury.ac.nz>	<5F6D8E70-1652-4F4B-B10D-69327623700C@gmail.com>
	<AANLkTik8WnYHBzJGpPqJ+yvKHLU34kJRo4eduMCm5053@mail.gmail.com>
Message-ID: <i57j80$n7h$1@dough.gmane.org>


On 08/26/2010 07:25 PM, Guido van Rossum wrote:

> That's not my experience. I wrote a trampoline myself (not released
> yet), and found that I had to write a lot more code to deal with the
> absence of yield-from than to deal with returns. In my framework,
> users write 'raise Return(value)' where Return is a subclass of
> StopIteration. The trampoline code that must be written to deal with
> StopIteration can be extended trivially to deal with this. The only
> reason I chose to use a subclass is so that I can diagnose when the
> return value is not used, but I could have chosen to ignore this or
> just diagnose whenever the argument to StopIteration is not None.

I'm currently playing around with a trampoline version based on the example 
in PEP 342.  Some of the things I found are ...


* In my version I seperated the trampoline from the scheduler.  Having it 
as a seperate class made the code cleaner and easier to read.  A trampoline 
instance can be ran without the scheduler.  (An example of this is below.)

The separate Scheduler only needs a few methods in a coroutine wrapper to 
run it. It really doesn't matter what's inside it as long as it
has a resume method that the scheduler can understand, and it returns in a 
timely manner so it doesn't starve other coroutines.


* I've found that having a Coroutine class, that has the generator methods 
on it, is very useful for writing more complex coroutines and generators.


* In a true trampoline, all sub coroutines are yielded out to the 
trampoline resume loop before their send method is called, so "yield from" 
isn't needed with a well behaved Trampoline runner.

I think "yield from"'s value is that it emulates a trampolines performance 
without needing a stack to keep track of caller coroutines.  It also saves 
a lot of looping if you want to write coroutines with sub coroutines 
without a trampoline runner to run them on.


* Raising StopIteration(value) worked just fine for setting the last value.

Getting the value from the exception just before returning it is still a 
bit clumsy... I currently use.

      return exc.args[0] if exc.args else None

Maybe I've overlooked something?

My version of the Trampoline class handles the return value since it 
already has it handy when it gets a StopIteration exception, so the user 
doesn't need to this, they just need to yield the last value out the same 
as they do anywhere else.



I wonder if "yield from" may run into pythons stack limit?  For example...

"""
     Factorial Function.
"""
def f(n, k=1):
     if n != 0:
         return f(n-1, k*n)
     else:
         return k

def factoral(n):
     return f(n)

if __name__ == "__main__":
     print(factoral(1000))

This aborts with:
	RuntimeError: maximum recursion depth exceeded in comparison



This one works just fine.

"""
     Factorial Trampoline.
"""
from coroutine.scheduler import Trampoline

def tramp(func):
     def wrap(*args, **kwds):
         t = Trampoline(func(*args, **kwds))
         return t.run()
     return wrap


def f(n, k=1):
     if n != 0:
         yield f(n-1, k*n)
     else:
         yield k

@tramp
def factoral(n):
     yield f(n)

if __name__ == "__main__":
     print(factoral(10000))   # <---- extra zero too!


But if I add another zero, it begins to slow to a crawl as it uses swap 
space. ;-)

How would a "yield from" version compare?


I'm basically learning this stuff by trying to break this thing, and then 
trying to fix what breaks as I go.  That seems to be working. ;-)

Cheers,
    Ron Adam



From cs at zip.com.au  Fri Aug 27 10:03:37 2010
From: cs at zip.com.au (Cameron Simpson)
Date: Fri, 27 Aug 2010 18:03:37 +1000
Subject: [Python-Dev] Update Shell profile for ZSH on Mac OS
In-Reply-To: <AE735D9D-8281-473E-94AA-979ED43BCB46@gmail.com>
References: <AE735D9D-8281-473E-94AA-979ED43BCB46@gmail.com>
Message-ID: <20100827080337.GA17653@cskk.homeip.net>

On 26Aug2010 14:37, Sylvain Mora <sylvain.mora at googlemail.com> wrote:
| I use python for more than a year now and i bought a MacBook in July. I
| installed Python 2.7 using the .dmg archive on the official website. After
| the installation I launched the Update Shell Profile.command script,
| but it doesn't work with ZSH. That's why I have write a small patch to
| be able to use this script with ZSH shell.
| 
| He simply set the path fo zsh shell.
[...]
| +zsh)
| +        PR="${HOME}/.zshenv"

The equivalent of .profile/.bash_profile in zsh is the .zprofile file.
The .zshenv is not where your account setup should live and is not what
should be used in this patch.

Cheers,
-- 
Cameron Simpson <cs at zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/

Shape without form, shade without colour,
Paralysed force, gesture without motion;        - T.S. Eliot, _The Hollow Men_

From asmodai at in-nomine.org  Fri Aug 27 10:46:56 2010
From: asmodai at in-nomine.org (Jeroen Ruigrok van der Werven)
Date: Fri, 27 Aug 2010 10:46:56 +0200
Subject: [Python-Dev] Fwd:  i18n
In-Reply-To: <AANLkTi=Ss+ZK_GnxrkaC_O-YAHMDxWHL34qVAcvAJvu1@mail.gmail.com>
References: <AANLkTinv=a8f3kO56CJ3FUgSZPh23fuSs7zyaofj=GMM@mail.gmail.com>
	<20100814081816.GC49566@nexus.in-nomine.org>
	<AANLkTinAYVWrqw2tO3DaY7rb+n8xLQgv6ri_RkxwYCJH@mail.gmail.com>
	<AANLkTim62674F3w-c8gaUggco0uuwJAD_a+7b-DGrgRN@mail.gmail.com>
	<AANLkTi=Ss+ZK_GnxrkaC_O-YAHMDxWHL34qVAcvAJvu1@mail.gmail.com>
Message-ID: <20100827084655.GQ49566@nexus.in-nomine.org>

-On [20100825 20:03], Alcino Dall'Igna Jr (adijbr at gmail.com) wrote:
>If (3) could enter the main trunk it would be a great help by itself.
>In this case access to international help is useless due the original
>difficulties with the language, remember I'm talking about kids
>mainly, and 1st stage to programming for youngsters. There are two
>main ways to do this, one is using codes as indicated, but I prefer
>using the more generally accepted and used, with messages catalogs
>using gettext and the like.

Haven't been able to respond sooner, but maybe one thing was not so clear
about what I wrote since you misrepresented it here. What I was referring to
was this scenario:

ImportError: No module named blah

would become in nl_NL something like:

ImportError: Geen module genaamd blah

Now, if ImportError (or any other error) has only one text, then I could
copy-paste that error message easily and people would understand
contextually from the error which it is, despite the localization.

However, if there's multiple possible messages, how is someone else supposed
to figure out what my localized message means in order to help me out? In
this case I think an approach with a number inventory system works out well,
e.g.:

ImportError (3): Geen module genaamd blah

And the 3 would be a stable number for this particular message.

More examples:

http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.help.ase_15.0.sag1/html/sag1/sag1485.htm

Oracle:
en_US: ORA-00942: table or view does not exist
ja_JP: ORA-00942: ???????????????


-- 
Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
????? ?????? ??? ?? ??????
http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B
When you meet a master in the street, do not speak, do not be silent. Then
how will you greet him?

From cmjohnson.mailinglist at gmail.com  Fri Aug 27 11:35:53 2010
From: cmjohnson.mailinglist at gmail.com (Carl M. Johnson)
Date: Thu, 26 Aug 2010 23:35:53 -1000
Subject: [Python-Dev] Fwd: i18n
In-Reply-To: <9B1795C95533CA46A83BA1EAD4B010307007C8@flonidanmail.flonidan.net>
References: <AANLkTinv=a8f3kO56CJ3FUgSZPh23fuSs7zyaofj=GMM@mail.gmail.com>
	<20100814081816.GC49566@nexus.in-nomine.org>
	<AANLkTinAYVWrqw2tO3DaY7rb+n8xLQgv6ri_RkxwYCJH@mail.gmail.com>
	<AANLkTim62674F3w-c8gaUggco0uuwJAD_a+7b-DGrgRN@mail.gmail.com>
	<AANLkTi=Ss+ZK_GnxrkaC_O-YAHMDxWHL34qVAcvAJvu1@mail.gmail.com>
	<AANLkTimq5vF3WqpDZHe1W4ruYiNb1qbYFgRha8iSUEaF@mail.gmail.com>
	<4C75617A.6050204@voidspace.org.uk> <i53u8r$fol$1@dough.gmane.org>
	<9B1795C95533CA46A83BA1EAD4B010307007C8@flonidanmail.flonidan.net>
Message-ID: <AANLkTi=w+okFxVUX0Qtarq+a5xMu-PTHTnr34K14n1mw@mail.gmail.com>

On Wed, Aug 25, 2010 at 10:42 PM, Anders J. Munch <ajm at flonidan.dk> wrote:

> This could be done as a free-standing library, there's no reason to
> involve core CPython. ?Just do message translation at a later stage,
> e.g. in a custom sys.excepthook.

It could be done as a free standing library, but if this idea gets
traction, it might be nice to incorporate it into the standard
library, so inexperienced Pythoneers wouldn't have to do anything more
onerous than "import localizedexceptions" in their interactive
console. Using easy_install or whatever to add a new module can be
tough in, say, a school environment where you don't have control of
the machines you are using. I suppose the sensible thing to do is to
recruit people for an independent project first and see if it gains
traction. If it does, then pull it into the standard library a few
years down the road.

Incidentally, on the topic of translating keywords and such, it looks
like one project to do so, Chinese Python, hasn't been updated since
2004: http://www.chinesepython.org/cgi_bin/cgb.cgi/news/news.html

I just don't think there's much demand for translating the keywords.

-- Carl Johnson

From chef at ghum.de  Fri Aug 27 12:00:13 2010
From: chef at ghum.de (Massa, Harald Armin)
Date: Fri, 27 Aug 2010 12:00:13 +0200
Subject: [Python-Dev] Fwd: i18n
In-Reply-To: <AANLkTi=w+okFxVUX0Qtarq+a5xMu-PTHTnr34K14n1mw@mail.gmail.com>
References: <AANLkTinv=a8f3kO56CJ3FUgSZPh23fuSs7zyaofj=GMM@mail.gmail.com>
	<20100814081816.GC49566@nexus.in-nomine.org>
	<AANLkTinAYVWrqw2tO3DaY7rb+n8xLQgv6ri_RkxwYCJH@mail.gmail.com>
	<AANLkTim62674F3w-c8gaUggco0uuwJAD_a+7b-DGrgRN@mail.gmail.com>
	<AANLkTi=Ss+ZK_GnxrkaC_O-YAHMDxWHL34qVAcvAJvu1@mail.gmail.com>
	<AANLkTimq5vF3WqpDZHe1W4ruYiNb1qbYFgRha8iSUEaF@mail.gmail.com>
	<4C75617A.6050204@voidspace.org.uk> <i53u8r$fol$1@dough.gmane.org>
	<9B1795C95533CA46A83BA1EAD4B010307007C8@flonidanmail.flonidan.net>
	<AANLkTi=w+okFxVUX0Qtarq+a5xMu-PTHTnr34K14n1mw@mail.gmail.com>
Message-ID: <AANLkTi=-UeU=_xeX4wcSh6z6rQzxrC+B6BEv1nswLg66@mail.gmail.com>

>
> Incidentally, on the topic of translating keywords and such, it looks
> like one project to do so, Chinese Python, hasn't been updated since
> 2004: http://www.chinesepython.org/cgi_bin/cgb.cgi/news/news.html
>
> I just don't think there's much demand for translating the keywords.
>
> I really want to to beg everybody to never localize the keywords. Microsoft
did this with their Word and Excel-Functions, and it is a source of
frustration.

While learning any programming language, you're learning new concepts
anyway. new concepts = new words.

Harald


-- 
GHUM Harald Massa
persuadere et programmare
Harald Armin Massa
Spielberger Stra?e 49
70435 Stuttgart
0173/9409607
no fx, no carrier pigeon
-
Using PostgreSQL is mostly about sleeping well at night.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100827/d3cda392/attachment.html>

From sylvain.mora at googlemail.com  Fri Aug 27 13:11:55 2010
From: sylvain.mora at googlemail.com (Sylvain Mora)
Date: Fri, 27 Aug 2010 13:11:55 +0200
Subject: [Python-Dev] Update Shell profile for ZSH on Mac OS
In-Reply-To: <20100827080337.GA17653@cskk.homeip.net>
References: <AE735D9D-8281-473E-94AA-979ED43BCB46@gmail.com>
	<20100827080337.GA17653@cskk.homeip.net>
Message-ID: <53F42CEB-8E51-402D-BE64-0CFDD955EB7A@gmail.com>

Hi !

> Ronald Oussoren.  If you select Components -> Macintosh in the bug 
> tracker when opening a new bug it will be assigned automatically; if 
> not, someone will see it and update appropriately.

Thank you, I have never used a bug tracker. The next time i shall know.

Le 27 ao?t 2010 ? 10:03, Cameron Simpson a ?crit :

> On 26Aug2010 14:37, Sylvain Mora <sylvain.mora at googlemail.com> wrote:
> | I use python for more than a year now and i bought a MacBook in July. I
> | installed Python 2.7 using the .dmg archive on the official website. After
> | the installation I launched the Update Shell Profile.command script,
> | but it doesn't work with ZSH. That's why I have write a small patch to
> | be able to use this script with ZSH shell.
> | 
> | He simply set the path fo zsh shell.
> [...]
> | +zsh)
> | +        PR="${HOME}/.zshenv"
> 
> The equivalent of .profile/.bash_profile in zsh is the .zprofile file.
> The .zshenv is not where your account setup should live and is not what
> should be used in this patch.

You are right, I have the bad habit to use this file.
I am going to modify the patch before putting him on the tracker.

Best regards,
Sylvain


From status at bugs.python.org  Fri Aug 27 18:07:49 2010
From: status at bugs.python.org (Python tracker)
Date: Fri, 27 Aug 2010 18:07:49 +0200 (CEST)
Subject: [Python-Dev] Summary of Python tracker Issues
Message-ID: <20100827160749.EF53E781BB@psf.upfronthosting.co.za>


ACTIVITY SUMMARY (2010-08-20 - 2010-08-27)
Python tracker at http://bugs.python.org/

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

Issues stats:
  open    2560 (+41)
  closed 18924 (+114)
  total  21484 (+52)

Open issues with patches: 1093 


Issues opened (41)
==================

#7005: ConfigParser does not handle options without values
http://bugs.python.org/issue7005  reopened by fdrake

#8589: test_warnings.CEnvironmentVariableTests.test_nonascii fails un
http://bugs.python.org/issue8589  reopened by flox

#9287: Minor fix in test_file2k.OtherFileTests.testOpenDir
http://bugs.python.org/issue9287  reopened by eric.araujo

#9651: ctypes crash when writing zerolength string buffer to file
http://bugs.python.org/issue9651  opened by andbj

#9652: Tidy argparse default output
http://bugs.python.org/issue9652  opened by Tom.Browder

#9653: New default argparse output to be added
http://bugs.python.org/issue9653  opened by Tom.Browder

#9654: merge PC/getpathp.c into Modules/getpath.c
http://bugs.python.org/issue9654  opened by amaury.forgeotdarc

#9660: PEP 383: socket module doesn't handle undecodable protocol or 
http://bugs.python.org/issue9660  opened by baikie

#9662: ctypes not building under OS X because of ffi_closure_free not
http://bugs.python.org/issue9662  opened by brett.cannon

#9663: importlib should exclusively open bytecode files
http://bugs.python.org/issue9663  opened by brett.cannon

#9664: Make gzip module not require that underlying file object suppo
http://bugs.python.org/issue9664  opened by doko

#9665: Buid issues on Cygwin - _curses, _curses_panel, and _io
http://bugs.python.org/issue9665  opened by brian.curtin

#9667: NetBSD curses KEY_* constants
http://bugs.python.org/issue9667  opened by bgreen

#9668: strings in json.dump in '' instead of ""
http://bugs.python.org/issue9668  opened by refresh

#9669: regexp: zero-width matches in MIN_UNTIL
http://bugs.python.org/issue9669  opened by arigo

#9670: Exceed Recursion Limit in Thread
http://bugs.python.org/issue9670  opened by jaredlang

#9671: test_executable_without_cwd fails: AssertionError: 1 != 47
http://bugs.python.org/issue9671  opened by srid

#9672: test_xpickle fails on Windows: invokes pythonx.y instead of py
http://bugs.python.org/issue9672  opened by srid

#9673: Entry Widget Not Editable under Windows XP
http://bugs.python.org/issue9673  opened by firatozgul

#9674: make install DESTDIR=/home/blah fails when the prefix specifie
http://bugs.python.org/issue9674  opened by mailtome

#9675: segfault: PyDict_SetItem: Assertion `value' failed.
http://bugs.python.org/issue9675  opened by flox

#9677: "Global Module Index" link dead
http://bugs.python.org/issue9677  opened by brett.cannon

#9678: uuid._ifconfig_getnode can't work on NetBSD
http://bugs.python.org/issue9678  opened by shimizukawa

#9679: unicode DNS names in urllib, urlopen
http://bugs.python.org/issue9679  opened by loewis

#9682: socket.create_connection error message for domain subpart	with
http://bugs.python.org/issue9682  opened by r.david.murray

#9683: Dead code in py3k inspect module
http://bugs.python.org/issue9683  opened by Trundle

#9685: tuples should remember their hash value
http://bugs.python.org/issue9685  opened by dtorp

#9686: asyncore infinite loop on raise
http://bugs.python.org/issue9686  opened by mmw

#9687: dbmmodule.c:dbm_contains fails on 64bit big-endian (test_dbm.p
http://bugs.python.org/issue9687  opened by dmalcolm

#9691: sdist includes files that are not in MANIFEST.in
http://bugs.python.org/issue9691  opened by ronaldoussoren

#9692: UnicodeDecodeError in ElementTree.tostring()
http://bugs.python.org/issue9692  opened by uis

#9693: asynchat push_callable() patch
http://bugs.python.org/issue9693  opened by giampaolo.rodola

#9694: argparse: Default Help Message Lists Required Args As Optional
http://bugs.python.org/issue9694  opened by benschmaus

#9695: Return from generators in Python 3.2
http://bugs.python.org/issue9695  opened by Yury.Selivanov

#9696: xdrlib's pack_int generates DeprecationWarnings for negative i
http://bugs.python.org/issue9696  opened by dep

#9698: When reusing an handler, urllib(2)'s digest authentication fai
http://bugs.python.org/issue9698  opened by Luci.Stanescu

#9699: invalid call of Windows API _popen() generating The input line
http://bugs.python.org/issue9699  opened by sorin

#9700: semaphore errors on AIX 6.1
http://bugs.python.org/issue9700  opened by sable

#9701: Update ZSH profile on Mac OS installation
http://bugs.python.org/issue9701  opened by solevis

#1172011: BaseCookie should call value_decode from __getitem__
http://bugs.python.org/issue1172011  reopened by r.david.murray

#877904: freeze: problems excluding site
http://bugs.python.org/issue877904  reopened by r.david.murray



Most recent 15 issues with no replies (15)
==========================================

#9701: Update ZSH profile on Mac OS installation
http://bugs.python.org/issue9701

#9700: semaphore errors on AIX 6.1
http://bugs.python.org/issue9700

#9698: When reusing an handler, urllib(2)'s digest authentication fai
http://bugs.python.org/issue9698

#9693: asynchat push_callable() patch
http://bugs.python.org/issue9693

#9691: sdist includes files that are not in MANIFEST.in
http://bugs.python.org/issue9691

#9678: uuid._ifconfig_getnode can't work on NetBSD
http://bugs.python.org/issue9678

#9671: test_executable_without_cwd fails: AssertionError: 1 != 47
http://bugs.python.org/issue9671

#9669: regexp: zero-width matches in MIN_UNTIL
http://bugs.python.org/issue9669

#9667: NetBSD curses KEY_* constants
http://bugs.python.org/issue9667

#9664: Make gzip module not require that underlying file object suppo
http://bugs.python.org/issue9664

#9647: os.confstr() does not handle value changing length between cal
http://bugs.python.org/issue9647

#9645: PEP 383: os.pathconf() does not accept surrogateescape argumen
http://bugs.python.org/issue9645

#9644: PEP 383: os.statvfs() does not accept surrogateescape argument
http://bugs.python.org/issue9644

#9625: argparse: Problem with defaults for variable nargs
http://bugs.python.org/issue9625

#9621: Graphviz output for 2to3 fixer patterns
http://bugs.python.org/issue9621



Most recent 15 issues waiting for review (15)
=============================================

#9701: Update ZSH profile on Mac OS installation
http://bugs.python.org/issue9701

#9700: semaphore errors on AIX 6.1
http://bugs.python.org/issue9700

#9695: Return from generators in Python 3.2
http://bugs.python.org/issue9695

#9693: asynchat push_callable() patch
http://bugs.python.org/issue9693

#9687: dbmmodule.c:dbm_contains fails on 64bit big-endian (test_dbm.p
http://bugs.python.org/issue9687

#9683: Dead code in py3k inspect module
http://bugs.python.org/issue9683

#9678: uuid._ifconfig_getnode can't work on NetBSD
http://bugs.python.org/issue9678

#9677: "Global Module Index" link dead
http://bugs.python.org/issue9677

#9675: segfault: PyDict_SetItem: Assertion `value' failed.
http://bugs.python.org/issue9675

#9674: make install DESTDIR=/home/blah fails when the prefix specifie
http://bugs.python.org/issue9674

#9665: Buid issues on Cygwin - _curses, _curses_panel, and _io
http://bugs.python.org/issue9665

#9660: PEP 383: socket module doesn't handle undecodable protocol or 
http://bugs.python.org/issue9660

#9651: ctypes crash when writing zerolength string buffer to file
http://bugs.python.org/issue9651

#9645: PEP 383: os.pathconf() does not accept surrogateescape argumen
http://bugs.python.org/issue9645

#9644: PEP 383: os.statvfs() does not accept surrogateescape argument
http://bugs.python.org/issue9644



Top 10 most discussed issues (10)
=================================

#9694: argparse: Default Help Message Lists Required Args As Optional
http://bugs.python.org/issue9694  11 msgs

#9665: Buid issues on Cygwin - _curses, _curses_panel, and _io
http://bugs.python.org/issue9665  10 msgs

#7415: PyUnicode_FromEncodedObject() uses PyObject_AsCharBuffer()
http://bugs.python.org/issue7415   9 msgs

#9119: Python download page needs to mention crypto code in	Windows i
http://bugs.python.org/issue9119   8 msgs

#9377: socket,	PEP 383: Mishandling of non-ASCII bytes in host/domain
http://bugs.python.org/issue9377   8 msgs

#2830: Copy cgi.escape() to html
http://bugs.python.org/issue2830   7 msgs

#4508: distutils compiler not handling spaces in path to output/src f
http://bugs.python.org/issue4508   6 msgs

#9650: format codes in time.strptime docstrings
http://bugs.python.org/issue9650   6 msgs

#9653: New default argparse output to be added
http://bugs.python.org/issue9653   6 msgs

#9674: make install DESTDIR=/home/blah fails when the prefix specifie
http://bugs.python.org/issue9674   6 msgs



Issues closed (114)
===================

#1081824: Rewrite of docs for compiler.visitor
http://bugs.python.org/issue1081824  closed by georg.brandl

#1748015: Module-level stack scopes have incorrect bindings.
http://bugs.python.org/issue1748015  closed by georg.brandl

#1502517: crash in expat when compiling with --enable-profiling
http://bugs.python.org/issue1502517  closed by BreamoreBoy

#1434: SocketServer creates non-blocking files
http://bugs.python.org/issue1434  closed by georg.brandl

#1503: test_xmlrpc is still flakey
http://bugs.python.org/issue1503  closed by georg.brandl

#2218: Enhanced hotshot profiler with high-resolution timer
http://bugs.python.org/issue2218  closed by georg.brandl

#2268: Fold slice constants
http://bugs.python.org/issue2268  closed by rhettinger

#2521: ABC caches should use weak refs
http://bugs.python.org/issue2521  closed by benjamin.peterson

#2595: Multiple integer overflows in imgfile extension module lead to
http://bugs.python.org/issue2595  closed by georg.brandl

#2899: Fixers find, rfind, etc in 'string' module
http://bugs.python.org/issue2899  closed by georg.brandl

#3246: configure: WARNING: sys/socket.h: present but cannot be compil
http://bugs.python.org/issue3246  closed by georg.brandl

#3417: make the fix_dict fixer smarter
http://bugs.python.org/issue3417  closed by benjamin.peterson

#3444: add warnings for intra-package imports
http://bugs.python.org/issue3444  closed by eric.araujo

#3710: Reference leak in thread._local
http://bugs.python.org/issue3710  closed by pitrou

#3825: Major reworking of Python 2.5.2 re module
http://bugs.python.org/issue3825  closed by georg.brandl

#4320: optparse: "1 2 3" should be seen as one string
http://bugs.python.org/issue4320  closed by georg.brandl

#4327: Patch: simplify complex constant assignment statements
http://bugs.python.org/issue4327  closed by georg.brandl

#4475: More verbose error message for Py_FindMethod
http://bugs.python.org/issue4475  closed by georg.brandl

#4500: Compiler warnings when compiling Python 3.0 with a C89 compile
http://bugs.python.org/issue4500  closed by georg.brandl

#4594: Can't compile with -O3, on ARM, with gcc 3.4.4
http://bugs.python.org/issue4594  closed by georg.brandl

#4596: 2to3 does not fail as early as possible.
http://bugs.python.org/issue4596  closed by georg.brandl

#4659: compilation warning in Modules/zipimport.c
http://bugs.python.org/issue4659  closed by georg.brandl

#4973: calendar formatyearpage returns bytes, not str
http://bugs.python.org/issue4973  closed by georg.brandl

#5556: interactive interpreter, source encoding
http://bugs.python.org/issue5556  closed by r.david.murray

#5911: built-in compile() should take encoding option.
http://bugs.python.org/issue5911  closed by benjamin.peterson

#7453: HPUX 11.00: socketmodule.c -- error 1588: "AI_PASSIVE" undefin
http://bugs.python.org/issue7453  closed by georg.brandl

#7579: Patch to add docstrings to msvcrt
http://bugs.python.org/issue7579  closed by brian.curtin

#7742: please avoid 'which' in Modules/ld_so_aix
http://bugs.python.org/issue7742  closed by skrah

#7871: Duplicate test method in test_heapq
http://bugs.python.org/issue7871  closed by rhettinger

#8250: Implement pkgutil APIs as described in PEP 376
http://bugs.python.org/issue8250  closed by eric.araujo

#8403: dis.dis gives different results if Ctrl-C is pressed
http://bugs.python.org/issue8403  closed by rhettinger

#8695: Issue while installing Python 2.6.5 in IBM AIX 6.1
http://bugs.python.org/issue8695  closed by BreamoreBoy

#8750: Many of MutableSet's methods assume that the other parameter i
http://bugs.python.org/issue8750  closed by stutzbach

#8781: 32-bit wchar_t doesn't need to be unsigned to be usable	(I thi
http://bugs.python.org/issue8781  closed by stutzbach

#9061: cgi.escape Can Lead To XSS Vulnerabilities
http://bugs.python.org/issue9061  closed by benjamin.peterson

#9129: DoS smtpd module vulnerability
http://bugs.python.org/issue9129  closed by giampaolo.rodola

#9157: Allow inspection of used decorators on a function
http://bugs.python.org/issue9157  closed by rhettinger

#9171: sysconfig module does not support -m option
http://bugs.python.org/issue9171  closed by eric.araujo

#9208: SMTPHandler in the logging module does not handle unicode stri
http://bugs.python.org/issue9208  closed by vinay.sajip

#9214: Most Set methods of KeysView and ItemsView do not work right
http://bugs.python.org/issue9214  closed by rhettinger

#433024: SRE: (?flag) isn't properly scoped
http://bugs.python.org/issue433024  closed by georg.brandl

#433027: SRE: (?-flag) is not supported.
http://bugs.python.org/issue433027  closed by georg.brandl

#9501: Logging shutdown regressions with weakrefs
http://bugs.python.org/issue9501  closed by vinay.sajip

#9512: logging.handlers.RotatingFileHandler - mode argument not respe
http://bugs.python.org/issue9512  closed by vinay.sajip

#9572: IOError or OSError in test_multiprocessing
http://bugs.python.org/issue9572  closed by brett.cannon

#9601: ftplib should accept 250 on MKD
http://bugs.python.org/issue9601  closed by giampaolo.rodola

#9617: Buffered IO shouldn't ignore incoming signals during a partial
http://bugs.python.org/issue9617  closed by pitrou

#9618: IDLE shell ignores all but first statement
http://bugs.python.org/issue9618  closed by terry.reedy

#9620: Python 2.7 IDLE fails on OS X 10.6
http://bugs.python.org/issue9620  closed by terry.reedy

#9622: Allow to set profile/trace function globally
http://bugs.python.org/issue9622  closed by terry.reedy

#9648: 2to3 doesn't convert "file" usage to an "open" equivalent
http://bugs.python.org/issue9648  closed by benjamin.peterson

#9649: wrong default for sort_keys in json module documentation
http://bugs.python.org/issue9649  closed by georg.brandl

#9655: urllib2 fails to retrieve a url which is handled correctly by 
http://bugs.python.org/issue9655  closed by orsenthil

#9656: compiler module provides wrong AST for extended slice of lengt
http://bugs.python.org/issue9656  closed by benjamin.peterson

#9657: Add circular imports test
http://bugs.python.org/issue9657  closed by pitrou

#9658: weakref.proxy unequal to its referent in 2.x
http://bugs.python.org/issue9658  closed by georg.brandl

#9659: frozenset, when subclassed will yield warning upon call to sup
http://bugs.python.org/issue9659  closed by benjamin.peterson

#9661: 2to3 except fixer does the wrong thing for certain raise state
http://bugs.python.org/issue9661  closed by benjamin.peterson

#9666: 'hasattr' fix to suppress only AttributeError
http://bugs.python.org/issue9666  closed by benjamin.peterson

#9676: Keyword to disambiguate python version
http://bugs.python.org/issue9676  closed by eric.araujo

#9680: Add in declaration order support for the dictionary passed in 
http://bugs.python.org/issue9680  closed by r.david.murray

#9681: small typo in online documentation
http://bugs.python.org/issue9681  closed by georg.brandl

#9684: PC/pyconfig.h should define SIZEOF_WCHAR_T
http://bugs.python.org/issue9684  closed by stutzbach

#9688: object.__basicsize__ is erroneously 0 on big-endian 64-bit mac
http://bugs.python.org/issue9688  closed by benjamin.peterson

#9689: threading.Timer poorly documented
http://bugs.python.org/issue9689  closed by georg.brandl

#9690: Cannot distinguish b"str" from "str" in ast module.
http://bugs.python.org/issue9690  closed by benjamin.peterson

#9697: python 2.3.4  installation error on 64 bit env
http://bugs.python.org/issue9697  closed by eric.araujo

#9702: Python violates most users expectations via the modification d
http://bugs.python.org/issue9702  closed by loewis

#1027206: unicode DNS names in socket, urllib, urlopen
http://bugs.python.org/issue1027206  closed by loewis

#1223976: error locale.getlocale() with LANGUAGE=eu_ES
http://bugs.python.org/issue1223976  closed by lemburg

#231540: threads and profiler don't work together
http://bugs.python.org/issue231540  closed by georg.brandl

#1390197: tempfile misses usecase which requirs renaming
http://bugs.python.org/issue1390197  closed by georg.brandl

#1078245: Python2.4: building '_socket' extension fails with `INET_ADD
http://bugs.python.org/issue1078245  closed by BreamoreBoy

#1495488: make altinstall installs pydoc
http://bugs.python.org/issue1495488  closed by BreamoreBoy

#1194222: parsedate and Y2K
http://bugs.python.org/issue1194222  closed by r.david.murray

#1149447: bsddb wrapper does not export some low-level functions
http://bugs.python.org/issue1149447  closed by BreamoreBoy

#1589266: bdist_sunpkg distutils command
http://bugs.python.org/issue1589266  closed by eric.araujo

#1578999: PyArg_ParseTuple corrections
http://bugs.python.org/issue1578999  closed by BreamoreBoy

#1563079: code.InteractiveConsole() and closed sys.stdout
http://bugs.python.org/issue1563079  closed by BreamoreBoy

#1459279: sgmllib.SGMLparser and hexadecimal numeric character refs
http://bugs.python.org/issue1459279  closed by BreamoreBoy

#1524938: PEP MemoryError with a lot of available memory gc not called
http://bugs.python.org/issue1524938  closed by loewis

#1492240: Socket-object convenience function: getpeercred().
http://bugs.python.org/issue1492240  closed by BreamoreBoy

#1525343: Webserver TypeError: expected read buffer, NoneType found
http://bugs.python.org/issue1525343  closed by BreamoreBoy

#1230484: tokenize bug
http://bugs.python.org/issue1230484  closed by BreamoreBoy

#1433886: pointer aliasing causes core dump, with workaround
http://bugs.python.org/issue1433886  closed by benjamin.peterson

#1182788: ZipFile __del__/close problem with longint/long files
http://bugs.python.org/issue1182788  closed by amaury.forgeotdarc

#1122916: incorrect handle of declaration in markupbase
http://bugs.python.org/issue1122916  closed by BreamoreBoy

#1721518: Small case which hangs
http://bugs.python.org/issue1721518  closed by georg.brandl

#1527597: New module: miniconf
http://bugs.python.org/issue1527597  closed by BreamoreBoy

#1057417: New BaseSMTPServer module
http://bugs.python.org/issue1057417  closed by benjamin.peterson

#658749: asyncore connect() and winsock errors
http://bugs.python.org/issue658749  closed by giampaolo.rodola

#1254125: Python interpreter unnecessarily linked against c++ runtime
http://bugs.python.org/issue1254125  closed by BreamoreBoy

#1252236: Simplying Tkinter's event loop
http://bugs.python.org/issue1252236  closed by BreamoreBoy

#1233785: getpass.getpass() performs differently on Windows vs *nix
http://bugs.python.org/issue1233785  closed by BreamoreBoy

#1234473: configure: error: cannot compute sizeof (int), 77
http://bugs.python.org/issue1234473  closed by BreamoreBoy

#1489246: 2.4.3 fails to find Tcl/Tk on Solaris 10 x86_64
http://bugs.python.org/issue1489246  closed by BreamoreBoy

#1394135: Deleting first item causes anydbm.first() to fail
http://bugs.python.org/issue1394135  closed by BreamoreBoy

#1291169: mmap with unsigned int offset and cross build for ppc
http://bugs.python.org/issue1291169  closed by BreamoreBoy

#1465838: HP-UX11i: illegal combination of compilation and link flags
http://bugs.python.org/issue1465838  closed by georg.brandl

#843590: 'macintosh' encoding alias for 'mac_roman'
http://bugs.python.org/issue843590  closed by benjamin.peterson

#1637120: Python 2.5 fails to build on AIX 5.3 (xlc_r compiler)
http://bugs.python.org/issue1637120  closed by georg.brandl

#1303673: traceback on trying to load a hotshot stats file
http://bugs.python.org/issue1303673  closed by BreamoreBoy

#1205568: Compile fails on Darwin8 with --with-cxx=g++
http://bugs.python.org/issue1205568  closed by BreamoreBoy

#433029: SRE: posix classes aren't supported
http://bugs.python.org/issue433029  closed by georg.brandl

#1306253: Python 2.4.2c1 fails to build on 64-bit Solaris 10
http://bugs.python.org/issue1306253  closed by BreamoreBoy

#433030: SRE: Atomic Grouping (?>...) is not supported
http://bugs.python.org/issue433030  closed by georg.brandl

#1504333: sgmllib should allow angle brackets in quoted values
http://bugs.python.org/issue1504333  closed by BreamoreBoy

#1209447: os.path.join() fails if 2nd arg is a UNC path
http://bugs.python.org/issue1209447  closed by jpe

#849097: Request: getpos() for sgmllib
http://bugs.python.org/issue849097  closed by BreamoreBoy

#1608267: Create the DESTDIR as part of the make install process
http://bugs.python.org/issue1608267  closed by BreamoreBoy

#1229646: httplib error checking.
http://bugs.python.org/issue1229646  closed by BreamoreBoy

#1610654: cgi.py multipart/form-data
http://bugs.python.org/issue1610654  closed by BreamoreBoy

#1337876: Inconsistent use of buffer interface in string and unicode
http://bugs.python.org/issue1337876  closed by georg.brandl

#1581906: test_sqlite fails on OS X if test_ctypes is run
http://bugs.python.org/issue1581906  closed by BreamoreBoy

From solipsis at pitrou.net  Fri Aug 27 19:32:17 2010
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Fri, 27 Aug 2010 19:32:17 +0200
Subject: [Python-Dev] r84329 -
	python/branches/py3k/Lib/importlib/_bootstrap.py
References: <20100826210713.55E7CEE9B7@mail.python.org>
Message-ID: <20100827193217.5df897c0@pitrou.net>

On Thu, 26 Aug 2010 23:07:13 +0200 (CEST)
brett.cannon <python-checkins at python.org> wrote:
> Author: brett.cannon
> Date: Thu Aug 26 23:07:13 2010
> New Revision: 84329
> 
> Log:
> OSError is the exception raised when one tries to create a directory that
> already exists, not IOError.

It's probably simpler to catch all of them at once using
EnvironmentError.
(and see PEP 3151 :-))

Regards

Antoine.



From brett at python.org  Fri Aug 27 19:43:13 2010
From: brett at python.org (Brett Cannon)
Date: Fri, 27 Aug 2010 10:43:13 -0700
Subject: [Python-Dev] r84329 -
	python/branches/py3k/Lib/importlib/_bootstrap.py
In-Reply-To: <20100827193217.5df897c0@pitrou.net>
References: <20100826210713.55E7CEE9B7@mail.python.org>
	<20100827193217.5df897c0@pitrou.net>
Message-ID: <AANLkTikYPVfLiYwV2aeGFHnvvai7oqxUkuuwBvdB3CtP@mail.gmail.com>

On Fri, Aug 27, 2010 at 10:32, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Thu, 26 Aug 2010 23:07:13 +0200 (CEST)
> brett.cannon <python-checkins at python.org> wrote:
>> Author: brett.cannon
>> Date: Thu Aug 26 23:07:13 2010
>> New Revision: 84329
>>
>> Log:
>> OSError is the exception raised when one tries to create a directory that
>> already exists, not IOError.
>
> It's probably simpler to catch all of them at once using
> EnvironmentError.

It would be less code, but I like the clear separation.

> (and see PEP 3151 :-))

Oh, I want PEP 3151 as this little bit of code has shown me. As soon
as the PEP goes in I will clean this code up.

From tjreedy at udel.edu  Fri Aug 27 23:35:06 2010
From: tjreedy at udel.edu (Terry Reedy)
Date: Fri, 27 Aug 2010 17:35:06 -0400
Subject: [Python-Dev] Summary of Python tracker Issues
In-Reply-To: <20100827160749.EF53E781BB@psf.upfronthosting.co.za>
References: <20100827160749.EF53E781BB@psf.upfronthosting.co.za>
Message-ID: <i59b29$hdh$1@dough.gmane.org>

On 8/27/2010 12:07 PM, Python tracker wrote:

> Issues stats:
>    open    2560 (+41)
>    closed 18924 (+114)

I believe this is at least the 4th consecutive report in which closures 
outnumber opens. Total open is, at the moment, 2493, down from about 
2700, or maybe more, a couple of months ago. The simplification of 
having 2.7 on maintenance and 2.6 out of bug maintenance helps.

-- 
Terry Jan Reedy


From g.brandl at gmx.net  Sat Aug 28 01:12:18 2010
From: g.brandl at gmx.net (Georg Brandl)
Date: Sat, 28 Aug 2010 01:12:18 +0200
Subject: [Python-Dev] Released: Python 2.6.6
In-Reply-To: <4C7537A8.5070602@netwok.org>
References: <20100824153146.69874f04@heresy>
	<20100824191240.1457a3f0@heresy>	<4C74B23C.1010203@v.loewis.de>
	<4C7537A8.5070602@netwok.org>
Message-ID: <i59gue$7ks$1@dough.gmane.org>

Am 25.08.2010 17:32, schrieb ?ric Araujo:
>> The question really is whether there is any chance that they will get
>> released, in some form. There won't be further binary releases (at least
>> not from python.org), so there definitely won't be a CHM release.
> 
> I think that the most important release is docs.python.org/2.6,
> regardless of python.org/OS-specific downloadable doc packages.

Which is not updated from the branch anymore.  You will see that it redirects
to /releases/2.6.6, which is the docs released with 2.6.6.

> If people do like haypo and use the most recent docs instead of the
> version-specific ones, there?s indeed no need to bother with porting doc
> fixes and improvements. If people use docs.py.org/2.6 as a reference for
> some years while 2.7 is not on their systems, it may be worthwhile to
> keep updating those docs.

I do think that most people just use docs.python.org, and since we clearly
mark everything that is new in 2.7 there is no harm in doing so either.

I don't think I'll want to bother with porting doc fixes to the 2.6 branch.

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.


From greg.ewing at canterbury.ac.nz  Sat Aug 28 02:19:03 2010
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sat, 28 Aug 2010 12:19:03 +1200
Subject: [Python-Dev] Return from generators in Python 3.2
In-Reply-To: <i57j80$n7h$1@dough.gmane.org>
References: <3647704A-8952-4C14-A6EF-EF70E87497F8@gmail.com>
	<AANLkTimfKiNmeH5o6L73bELGSBPoJD7F_=2nZ0Xor4iD@mail.gmail.com>
	<46470DFD-4205-4FF0-8384-20DD4690FF58@gmail.com>
	<4C77011A.7070107@canterbury.ac.nz>
	<5F6D8E70-1652-4F4B-B10D-69327623700C@gmail.com>
	<AANLkTik8WnYHBzJGpPqJ+yvKHLU34kJRo4eduMCm5053@mail.gmail.com>
	<i57j80$n7h$1@dough.gmane.org>
Message-ID: <4C7855F7.1040608@canterbury.ac.nz>

Ron Adam wrote:

> I wonder if "yield from" may run into pythons stack limit?

My current implementation wouldn't, because nested yield-froms
don't result in nested activations of Python frames. But...

> if __name__ == "__main__":
>     print(factoral(10000))   # <---- extra zero too!
> 
> 
> But if I add another zero, it begins to slow to a crawl as it uses swap 
> space. ;-)
> 
> How would a "yield from" version compare?

... there is still a Python frame in existence for each
active invocation of the generator, so it would probably
use about the same amount of memory.

-- 
Greg

From merwok at netwok.org  Sat Aug 28 02:25:12 2010
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Sat, 28 Aug 2010 02:25:12 +0200
Subject: [Python-Dev] Released: Python 2.6.6
In-Reply-To: <i59gue$7ks$1@dough.gmane.org>
References: <20100824153146.69874f04@heresy>	<20100824191240.1457a3f0@heresy>	<4C74B23C.1010203@v.loewis.de>	<4C7537A8.5070602@netwok.org>
	<i59gue$7ks$1@dough.gmane.org>
Message-ID: <4C785768.3010604@netwok.org>

Thanks everyone for the feedback. I think my question has got good
answers (usage patterns, versionchanged/versionadded, lack of releases,
opinion of the doc editor), so it seems good for our users and for
developers to let the 2.6 docs in peace.

Regards, and a toast to 2.6.6!

From martin at v.loewis.de  Sat Aug 28 03:19:20 2010
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 28 Aug 2010 03:19:20 +0200
Subject: [Python-Dev] Released: Python 2.6.6
In-Reply-To: <4C785768.3010604@netwok.org>
References: <20100824153146.69874f04@heresy>	<20100824191240.1457a3f0@heresy>	<4C74B23C.1010203@v.loewis.de>	<4C7537A8.5070602@netwok.org>	<i59gue$7ks$1@dough.gmane.org>
	<4C785768.3010604@netwok.org>
Message-ID: <4C786418.80405@v.loewis.de>

> Regards, and a toast to 2.6.6!

Prost!

Martin

From martin at v.loewis.de  Sat Aug 28 12:04:10 2010
From: martin at v.loewis.de (=?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 28 Aug 2010 12:04:10 +0200
Subject: [Python-Dev] PEP 384 status
Message-ID: <4C78DF1A.1060601@v.loewis.de>

I have now started an initial patch for PEP 384, in the pep-0384 branch.
This has the following features:
- modules can be compiled under Py_LIMITED_API
- Tools/scripts/abitype.py converts C code containing static
  PyTypeObject definitions to use the new API for type definitions.

The following aspects are still missing:
- there is no support for generating python3.dll on Windows yet
- there has been no validation whether the API is actually feasible
  to use in extension modules.

I started looking into porting the sqlite extension, and ran into
these issues:
- certain fields of PyTypeObject are called directly:
  pysqlite_NodeType.tp_alloc
  Py_TYPE(self)->tp_free
- PyObject_Print is used, but can't be supported, as it uses a FILE*
  parameter

For the first issue, it would be possible to provide a generic
accessor function that fetches fields from a type object. Alternatively,
each case could be considered, suggesting an alternative code for the
desired effect.

I'll be off the net for the next two weeks most of the time, so
I might not be able to respond quickly.

Anybody interested in advancing that patch, feel free to commit
changes into the branch.

Regards,
Martin

From martin at v.loewis.de  Sat Aug 28 12:29:04 2010
From: martin at v.loewis.de (=?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 28 Aug 2010 12:29:04 +0200
Subject: [Python-Dev] versioned .so files for Python 3.2
In-Reply-To: <20100724002509.0ad8d359@snowdog>
References: <20100624115048.4fd152e3@heresy>	<AANLkTikrQiXeGtStA7BjHeda7m0XFwdbUHapzReA4UuD@mail.gmail.com>	<20100714195955.4815f980@heresy>
	<4C40372C.9030101@ubuntu.com>	<20100722164036.7a80d27c@snowdog>	<AANLkTinqPksuOBXxqt7TyfNFZh8oAqqF7hXfpcMjZ05r@mail.gmail.com>
	<20100724002509.0ad8d359@snowdog>
Message-ID: <4C78E4F0.9090306@v.loewis.de>

>> This leads me to a question: how do these configure options affect the
>> PEP 384 stable ABI? That PEP is currently silent on the issue, while
>> PEP 3149 appears to implicitly assume that "abi3" completely specifies
>> the ABI.
> 
> It's a great question - perhaps Martin can chime in?  It may be that 'abiX'
> isn't enough to fully specify compatible extension modules even when that
> module is written entirely and solely against PEP 384.  In that case, we may
> need to include the configure flags in the tag, e.g. foo.abi3-dmu.so.

The intention is that there is indeed just one stable ABI, so one
configuration is the supported one, and that should be the "default"
build.

As for the specific settings, my analysis would be this:
- pydebug: not supported by the stable ABI, as it changes the layout
  of PyObject, which is an exposed structure
  More specifically: Py_DEBUG, Py_TRACEREFS and Py_REF_DEBUG are
  all incompatible with the stable ABI
- pymalloc: I fail to see the impact on the ABI. All allocator
  macros become function calls under Py_LIMITED_API, otherwise,
  there shouldn't be any need to have different versions of that.
- wide-unicode: this is a tricky one. I'm tempted to say that the
  stable ABI should always use a Py_UNICODE that matches the platform's
  wchar_t. Alternative proposals are welcome.

Regards,
Martin

From benjamin at python.org  Sat Aug 28 15:40:36 2010
From: benjamin at python.org (Benjamin Peterson)
Date: Sat, 28 Aug 2010 08:40:36 -0500
Subject: [Python-Dev] PEP 384 status
In-Reply-To: <4C78DF1A.1060601@v.loewis.de>
References: <4C78DF1A.1060601@v.loewis.de>
Message-ID: <AANLkTimwkay5v6uUhXPtvPA94DfCBNvWd-2MVFPYZD0q@mail.gmail.com>

2010/8/28 "Martin v. L?wis" <martin at v.loewis.de>:
> I have now started an initial patch for PEP 384, in the pep-0384 branch.
> This has the following features:
> - modules can be compiled under Py_LIMITED_API
> - Tools/scripts/abitype.py converts C code containing static
> ?PyTypeObject definitions to use the new API for type definitions.
>
> The following aspects are still missing:
> - there is no support for generating python3.dll on Windows yet
> - there has been no validation whether the API is actually feasible
> ?to use in extension modules.
>
> I started looking into porting the sqlite extension, and ran into
> these issues:
> - certain fields of PyTypeObject are called directly:
> ?pysqlite_NodeType.tp_alloc
> ?Py_TYPE(self)->tp_free

This is from tp_new and tp_dealloc, right? I think we should probably
provide assessors PyObject_Alloc and PyObject_FreeObject.

> - PyObject_Print is used, but can't be supported, as it uses a FILE*
> ?parameter

I thought tp_print was supposed to have been removed. Anyway, if
sqlite is already using FILE *, then won't it be afflicted by the
Microsoft runtime version changes anyway? Maybe provide an extra flag
to enable FILE* APIs for those extensions that want to risk it?


-- 
Regards,
Benjamin

From martin at v.loewis.de  Sat Aug 28 20:52:54 2010
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Sat, 28 Aug 2010 20:52:54 +0200
Subject: [Python-Dev] PEP 384 status
In-Reply-To: <AANLkTimwkay5v6uUhXPtvPA94DfCBNvWd-2MVFPYZD0q@mail.gmail.com>
References: <4C78DF1A.1060601@v.loewis.de>
	<AANLkTimwkay5v6uUhXPtvPA94DfCBNvWd-2MVFPYZD0q@mail.gmail.com>
Message-ID: <4C795B06.1010903@v.loewis.de>

> This is from tp_new and tp_dealloc, right? I think we should probably
> provide assessors PyObject_Alloc and PyObject_FreeObject.

Correct, and yes, that sounds like a good approach.

>> - PyObject_Print is used, but can't be supported, as it uses a FILE*
>>  parameter
> 
> I thought tp_print was supposed to have been removed.

Yes - that should have happened for 3.0. Not sure how to deal with it now.

> Anyway, if
> sqlite is already using FILE *, then won't it be afflicted by the
> Microsoft runtime version changes anyway? Maybe provide an extra flag
> to enable FILE* APIs for those extensions that want to risk it?

For the sqlite extension, that wouldn't be a problem: if they build
with a different MSVC release, it will automatically link with a
different CRT, which then will have a consistent set of FILE objects.

The issue only arises if you pass FILE* across DLLs which in turn
are linked with different CRTs.

Regards,
Martin

From ncoghlan at gmail.com  Sun Aug 29 01:20:56 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 29 Aug 2010 09:20:56 +1000
Subject: [Python-Dev] PEP 384 status
In-Reply-To: <4C795B06.1010903@v.loewis.de>
References: <4C78DF1A.1060601@v.loewis.de>
	<AANLkTimwkay5v6uUhXPtvPA94DfCBNvWd-2MVFPYZD0q@mail.gmail.com>
	<4C795B06.1010903@v.loewis.de>
Message-ID: <AANLkTi=3TsqFCUvy623UCQSxRzq5DcW=xMikiod4bFcx@mail.gmail.com>

On Sun, Aug 29, 2010 at 4:52 AM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>> This is from tp_new and tp_dealloc, right? I think we should probably
>> provide assessors PyObject_Alloc and PyObject_FreeObject.
>
> Correct, and yes, that sounds like a good approach.
>
>>> - PyObject_Print is used, but can't be supported, as it uses a FILE*
>>> ?parameter
>>
>> I thought tp_print was supposed to have been removed.
>
> Yes - that should have happened for 3.0. Not sure how to deal with it now.

tp_print actually is gone, but PyObject_Print was retained. It just
relies on repr() and str() under the hood instead of the old tp_print
slot.

There are 4 operations performed on fp in that function: clearerr,
ferror, fprintf and fwrite.

There is also an implicit reference to errno (through
PyErr_SetFromErrno) which can't be trusted in a mixed CRT world
(PyErr_SetFromErrno() should be excluded from the Limited API, if it
isn't already, and replaced with a PyErr_SetFromErrnoEx which takes
the errno as an explicit argument. That assumes the CRTs will be
sufficiently compatible that strerror() will give the correct answer
for errno values from the other CRT. If that assumption is incorrect,
the new function would also need to accept a string argument for the
error description).

Four options come to mind:

- just leave it out of the limited API, extensions can do their own
thing to print objects
- leave PyObject_Print out of the limited API, but create a
PyObject_PrintEx that takes a Python IO stream via PyObject* rather
than a C level FILE*.
- leave PyObject_Print out of the limited API, but create a
PyObject_PrintEx that takes function pointers for the above 4
operations (so the FILE* pointer is only every operated on by
functions from the extension module's CRT)
- leave PyObject_Print out of the limited API, but create a
PyObject_PRINT macro that does much the same thing with the logic
rearranged so there is an inner function that figures out the string
to be printed, but an outer macro that does all the operations on the
FILE * object (so again, the FILE * is never passed to Python's CRT)

The last option requires the fewest adjustments for extension authors,
and it should be feasible to do it that way (even though it is a bit
of a hack). Something along the lines of the following:

#define PyObject_PRINT (obj, fp, flags, resultp) \
{ \
  int _result = -1;
  _t = _PyObject_PrintInner(obj, flags); \
  if (_t != NULL) { \
    clearerr(fp); \
    fwrite(PyBytes_AS_STRING(_t), 1, PyBytes_GET_SIZE(_t), fp); \
    Py_DECREF(_t); \
    if (ferror(fp)) { \
      PyErr_SetFromErrnoEx(PyExc_IOError, errno); \
      clearerr(fp); \
    } else { \
      _result = 0; \
    } \
  } \
  if (resultp != NULL) { \
    *resultp = _result; \
  } \
}


Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From solipsis at pitrou.net  Sun Aug 29 10:24:47 2010
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sun, 29 Aug 2010 10:24:47 +0200
Subject: [Python-Dev] PEP 384 status
References: <4C78DF1A.1060601@v.loewis.de>
	<AANLkTimwkay5v6uUhXPtvPA94DfCBNvWd-2MVFPYZD0q@mail.gmail.com>
	<4C795B06.1010903@v.loewis.de>
	<AANLkTi=3TsqFCUvy623UCQSxRzq5DcW=xMikiod4bFcx@mail.gmail.com>
Message-ID: <20100829102447.115448f2@pitrou.net>

On Sun, 29 Aug 2010 09:20:56 +1000
Nick Coghlan <ncoghlan at gmail.com> wrote:
> 
> Four options come to mind:
> 
> - just leave it out of the limited API, extensions can do their own
> thing to print objects
> - leave PyObject_Print out of the limited API, but create a
> PyObject_PrintEx that takes a Python IO stream via PyObject* rather
> than a C level FILE*.
> - leave PyObject_Print out of the limited API, but create a
> PyObject_PrintEx that takes function pointers for the above 4
> operations (so the FILE* pointer is only every operated on by
> functions from the extension module's CRT)
> - leave PyObject_Print out of the limited API, but create a
> PyObject_PRINT macro that does much the same thing with the logic
> rearranged so there is an inner function that figures out the string
> to be printed, but an outer macro that does all the operations on the
> FILE * object (so again, the FILE * is never passed to Python's CRT)

Fifth option:
- make PyObject_Print() an inline function (similar to your macro
  proposal), but only on Windows. This would retain the name and
  current signature. Apparently we could use something like
  "__forceinline" or "extern __forceinline"?

Regards

Antoine.



From ncoghlan at gmail.com  Sun Aug 29 10:41:45 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 29 Aug 2010 18:41:45 +1000
Subject: [Python-Dev] PEP 384 status
In-Reply-To: <20100829102447.115448f2@pitrou.net>
References: <4C78DF1A.1060601@v.loewis.de>
	<AANLkTimwkay5v6uUhXPtvPA94DfCBNvWd-2MVFPYZD0q@mail.gmail.com>
	<4C795B06.1010903@v.loewis.de>
	<AANLkTi=3TsqFCUvy623UCQSxRzq5DcW=xMikiod4bFcx@mail.gmail.com>
	<20100829102447.115448f2@pitrou.net>
Message-ID: <AANLkTikp+UW4dQZ-MZQ2ZDcVGSY2CVkvjgyxLA0V-FqQ@mail.gmail.com>

On Sun, Aug 29, 2010 at 6:24 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Sun, 29 Aug 2010 09:20:56 +1000
> Nick Coghlan <ncoghlan at gmail.com> wrote:
>>
>> Four options come to mind:
>>
>> - just leave it out of the limited API, extensions can do their own
>> thing to print objects
>> - leave PyObject_Print out of the limited API, but create a
>> PyObject_PrintEx that takes a Python IO stream via PyObject* rather
>> than a C level FILE*.
>> - leave PyObject_Print out of the limited API, but create a
>> PyObject_PrintEx that takes function pointers for the above 4
>> operations (so the FILE* pointer is only every operated on by
>> functions from the extension module's CRT)
>> - leave PyObject_Print out of the limited API, but create a
>> PyObject_PRINT macro that does much the same thing with the logic
>> rearranged so there is an inner function that figures out the string
>> to be printed, but an outer macro that does all the operations on the
>> FILE * object (so again, the FILE * is never passed to Python's CRT)
>
> Fifth option:
> - make PyObject_Print() an inline function (similar to your macro
> ?proposal), but only on Windows. This would retain the name and
> ?current signature. Apparently we could use something like
> ?"__forceinline" or "extern __forceinline"?

I believe both that option, and my third option, would run into
trouble due to the potential for errno confusion.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From solipsis at pitrou.net  Sun Aug 29 11:10:43 2010
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sun, 29 Aug 2010 11:10:43 +0200
Subject: [Python-Dev] PEP 384 status
In-Reply-To: <AANLkTikp+UW4dQZ-MZQ2ZDcVGSY2CVkvjgyxLA0V-FqQ@mail.gmail.com>
References: <4C78DF1A.1060601@v.loewis.de>
	<AANLkTimwkay5v6uUhXPtvPA94DfCBNvWd-2MVFPYZD0q@mail.gmail.com>
	<4C795B06.1010903@v.loewis.de>
	<AANLkTi=3TsqFCUvy623UCQSxRzq5DcW=xMikiod4bFcx@mail.gmail.com>
	<20100829102447.115448f2@pitrou.net>
	<AANLkTikp+UW4dQZ-MZQ2ZDcVGSY2CVkvjgyxLA0V-FqQ@mail.gmail.com>
Message-ID: <20100829111043.4d786fe6@pitrou.net>

On Sun, 29 Aug 2010 18:41:45 +1000
Nick Coghlan <ncoghlan at gmail.com> wrote:

> On Sun, Aug 29, 2010 at 6:24 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> > On Sun, 29 Aug 2010 09:20:56 +1000
> > Nick Coghlan <ncoghlan at gmail.com> wrote:
> >>
> >> Four options come to mind:
> >>
> >> - just leave it out of the limited API, extensions can do their own
> >> thing to print objects
> >> - leave PyObject_Print out of the limited API, but create a
> >> PyObject_PrintEx that takes a Python IO stream via PyObject* rather
> >> than a C level FILE*.
> >> - leave PyObject_Print out of the limited API, but create a
> >> PyObject_PrintEx that takes function pointers for the above 4
> >> operations (so the FILE* pointer is only every operated on by
> >> functions from the extension module's CRT)
> >> - leave PyObject_Print out of the limited API, but create a
> >> PyObject_PRINT macro that does much the same thing with the logic
> >> rearranged so there is an inner function that figures out the string
> >> to be printed, but an outer macro that does all the operations on the
> >> FILE * object (so again, the FILE * is never passed to Python's CRT)
> >
> > Fifth option:
> > - make PyObject_Print() an inline function (similar to your macro
> > ?proposal), but only on Windows. This would retain the name and
> > ?current signature. Apparently we could use something like
> > ?"__forceinline" or "extern __forceinline"?
> 
> I believe both that option, and my third option, would run into
> trouble due to the potential for errno confusion.

I don't understand. What's the difference with the macro you proposed
(the fourth option)?

Antoine.

From ncoghlan at gmail.com  Sun Aug 29 14:16:57 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 29 Aug 2010 22:16:57 +1000
Subject: [Python-Dev] PEP 384 status
In-Reply-To: <20100829111043.4d786fe6@pitrou.net>
References: <4C78DF1A.1060601@v.loewis.de>
	<AANLkTimwkay5v6uUhXPtvPA94DfCBNvWd-2MVFPYZD0q@mail.gmail.com>
	<4C795B06.1010903@v.loewis.de>
	<AANLkTi=3TsqFCUvy623UCQSxRzq5DcW=xMikiod4bFcx@mail.gmail.com>
	<20100829102447.115448f2@pitrou.net>
	<AANLkTikp+UW4dQZ-MZQ2ZDcVGSY2CVkvjgyxLA0V-FqQ@mail.gmail.com>
	<20100829111043.4d786fe6@pitrou.net>
Message-ID: <AANLkTimoTeQODqxqwhnLKVj6E1YG9g_+UaNtuV_nUZ0C@mail.gmail.com>

On Sun, Aug 29, 2010 at 7:10 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Sun, 29 Aug 2010 18:41:45 +1000
> Nick Coghlan <ncoghlan at gmail.com> wrote:
>> I believe both that option, and my third option, would run into
>> trouble due to the potential for errno confusion.
>
> I don't understand. What's the difference with the macro you proposed
> (the fourth option)?

Oh, you meant combining it with the suggested change to the errno
handling rather than merely inlining the existing PyObject_Print? Yes,
that should work and would be even more seamless from the point of
view of the extension modules.

However, since even platforms other than Windows aren't immune to
version upgrades of the standard C runtime, I'm still more comfortable
with the idea that the strict ABI should refuse to pass FILE* pointers
across extension module boundaries. The advantage of the preprocessor
macro approach is that it allows us to provide assistance with
operations on FILE* pointers while still obeying that restriction
regardless of the specific compilers involved in creating the Python
and extension module binaries.

It would be nice to get rid of the resultp parameter by rewriting the
internals of the macro as a collection of ternary and comma
expressions instead of a scope, but I haven't managed to crack the
problem of feeding the correct arguments to fwrite with that approach
(it's been quite a while since I've attempted to abuse C expressions
to this extent, so I've forgotten most of the tricks for avoiding
temporary variables).

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From solipsis at pitrou.net  Sun Aug 29 17:43:14 2010
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sun, 29 Aug 2010 17:43:14 +0200
Subject: [Python-Dev] PEP 384 status
In-Reply-To: <AANLkTimoTeQODqxqwhnLKVj6E1YG9g_+UaNtuV_nUZ0C@mail.gmail.com>
References: <4C78DF1A.1060601@v.loewis.de>
	<AANLkTimwkay5v6uUhXPtvPA94DfCBNvWd-2MVFPYZD0q@mail.gmail.com>
	<4C795B06.1010903@v.loewis.de>
	<AANLkTi=3TsqFCUvy623UCQSxRzq5DcW=xMikiod4bFcx@mail.gmail.com>
	<20100829102447.115448f2@pitrou.net>
	<AANLkTikp+UW4dQZ-MZQ2ZDcVGSY2CVkvjgyxLA0V-FqQ@mail.gmail.com>
	<20100829111043.4d786fe6@pitrou.net>
	<AANLkTimoTeQODqxqwhnLKVj6E1YG9g_+UaNtuV_nUZ0C@mail.gmail.com>
Message-ID: <20100829174314.7129953a@pitrou.net>

On Sun, 29 Aug 2010 22:16:57 +1000
Nick Coghlan <ncoghlan at gmail.com> wrote:
> 
> However, since even platforms other than Windows aren't immune to
> version upgrades of the standard C runtime, I'm still more comfortable
> with the idea that the strict ABI should refuse to pass FILE* pointers
> across extension module boundaries.

I'm not sure what the worry is. Under an Unix-like system, there
shouldn't be any situation where two different versions of the libc are
loaded in the same process. And since FILE* is an opaque pointer
whose referent is only accessed by the libc, things should be fine.

(actually, I'm baffled that Windows has such problems, and I would
suggest that it's not Python's job to shield Windows
application developers from Windows-specific development issues)

> The advantage of the preprocessor
> macro approach is that it allows us to provide assistance with
> operations on FILE* pointers while still obeying that restriction
> regardless of the specific compilers involved in creating the Python
> and extension module binaries.

An inline function should provide the same advantage since it will be
compiled with the calling library/executable, rather than the Python
DLL.

Regards

Antoine.

From foom at fuhm.net  Sun Aug 29 14:51:18 2010
From: foom at fuhm.net (James Y Knight)
Date: Sun, 29 Aug 2010 08:51:18 -0400
Subject: [Python-Dev] PEP 384 status
In-Reply-To: <AANLkTimoTeQODqxqwhnLKVj6E1YG9g_+UaNtuV_nUZ0C@mail.gmail.com>
References: <4C78DF1A.1060601@v.loewis.de>
	<AANLkTimwkay5v6uUhXPtvPA94DfCBNvWd-2MVFPYZD0q@mail.gmail.com>
	<4C795B06.1010903@v.loewis.de>
	<AANLkTi=3TsqFCUvy623UCQSxRzq5DcW=xMikiod4bFcx@mail.gmail.com>
	<20100829102447.115448f2@pitrou.net>
	<AANLkTikp+UW4dQZ-MZQ2ZDcVGSY2CVkvjgyxLA0V-FqQ@mail.gmail.com>
	<20100829111043.4d786fe6@pitrou.net>
	<AANLkTimoTeQODqxqwhnLKVj6E1YG9g_+UaNtuV_nUZ0C@mail.gmail.com>
Message-ID: <F504D865-ABAC-4C64-B28F-A5E4A4C9BA59@fuhm.net>

On Aug 29, 2010, at 8:16 AM, Nick Coghlan wrote:
> However, since even platforms other than Windows aren't immune to
> version upgrades of the standard C runtime

Aren't they? I don't know of any other platform that lets you have two versions of libc linked into a single address space. Linux has had incompatible libc updates in the past, but it was not possible to use both in one program.

I believe BSD works the same way.

James

From solipsis at pitrou.net  Sun Aug 29 23:23:12 2010
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sun, 29 Aug 2010 23:23:12 +0200
Subject: [Python-Dev] r84355 - python/branches/py3k/Lib/test/test_ssl.py
References: <20100829205656.59639EE99A@mail.python.org>
Message-ID: <20100829232312.760b8214@pitrou.net>

On Sun, 29 Aug 2010 22:56:56 +0200 (CEST)
giampaolo.rodola <python-checkins at python.org> wrote:
> +        with self.assertRaises(IOError) as err:
> +            ssl.wrap_socket(socket.socket(), certfile=WRONGCERT)
> +            self.assertEqual(err.errno, errno.ENOENT)

The assertEqual will never get executed since the previous line raises.

> +        with self.assertRaises(IOError) as err:
> +            ssl.wrap_socket(socket.socket(), certfile=WRONGCERT, keyfile=WRONGCERT)
> +            self.assertEqual(err.errno, errno.ENOENT)

Same here.



From fuzzyman at voidspace.org.uk  Sun Aug 29 23:25:49 2010
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Mon, 30 Aug 2010 00:25:49 +0300
Subject: [Python-Dev] r84355 - python/branches/py3k/Lib/test/test_ssl.py
In-Reply-To: <20100829232312.760b8214@pitrou.net>
References: <20100829205656.59639EE99A@mail.python.org>
	<20100829232312.760b8214@pitrou.net>
Message-ID: <4C7AD05D.2030102@voidspace.org.uk>

  On 30/08/2010 00:23, Antoine Pitrou wrote:
> On Sun, 29 Aug 2010 22:56:56 +0200 (CEST)
> giampaolo.rodola<python-checkins at python.org>  wrote:
>> +        with self.assertRaises(IOError) as err:
>> +            ssl.wrap_socket(socket.socket(), certfile=WRONGCERT)
>> +            self.assertEqual(err.errno, errno.ENOENT)
> The assertEqual will never get executed since the previous line raises.

If it is dedented once then it will work (in Python 2.7 / 3.2).

Michael
>> +        with self.assertRaises(IOError) as err:
>> +            ssl.wrap_socket(socket.socket(), certfile=WRONGCERT, keyfile=WRONGCERT)
>> +            self.assertEqual(err.errno, errno.ENOENT)
> Same here.
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at 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/


From ncoghlan at gmail.com  Sun Aug 29 23:31:34 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 30 Aug 2010 07:31:34 +1000
Subject: [Python-Dev] PEP 384 status
In-Reply-To: <20100829174314.7129953a@pitrou.net>
References: <4C78DF1A.1060601@v.loewis.de>
	<AANLkTimwkay5v6uUhXPtvPA94DfCBNvWd-2MVFPYZD0q@mail.gmail.com>
	<4C795B06.1010903@v.loewis.de>
	<AANLkTi=3TsqFCUvy623UCQSxRzq5DcW=xMikiod4bFcx@mail.gmail.com>
	<20100829102447.115448f2@pitrou.net>
	<AANLkTikp+UW4dQZ-MZQ2ZDcVGSY2CVkvjgyxLA0V-FqQ@mail.gmail.com>
	<20100829111043.4d786fe6@pitrou.net>
	<AANLkTimoTeQODqxqwhnLKVj6E1YG9g_+UaNtuV_nUZ0C@mail.gmail.com>
	<20100829174314.7129953a@pitrou.net>
Message-ID: <AANLkTi=GXRQKObnou5mbS2kZ25Axics7Jr+KiuePveg_@mail.gmail.com>

On Mon, Aug 30, 2010 at 1:43 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Sun, 29 Aug 2010 22:16:57 +1000
> Nick Coghlan <ncoghlan at gmail.com> wrote:
> (actually, I'm baffled that Windows has such problems, and I would
> suggest that it's not Python's job to shield Windows
> application developers from Windows-specific development issues)

It depends on how you view different versions of a shared library -
with relocatable addresses, there's nothing fundamental preventing you
from allowing separately compiled components to depend on those
different versions, with the dynamic linker placing them at different
points in memory. If you start from an independent binary distribution
mindset and an attitude that the easiest way to ensure backwards
compatibility is to avoid forced upgrades of dependencies, allowing it
makes perfect sense (whereas *nix systems tend work to with a "don't
repeat yourself" philosophy at the system level and are quite happy to
let old binaries and source code become unusable, or at least
incompatible with modern components, as their dependencies update
below them). With the benefit of hindsight, the Windows approach turns
out to have some pretty severe downsides (the name "DLL hell" is well
earned), but there are some positive aspects to the approach.

Back on the main topic, I am not in a position to state that Windows
is the only platform that currently, or will ever, allow two different
versions of the C runtime to be loaded into the same address space (I
thought you could even persuade *nix to do it if you really wanted to,
although you tell me I'm wrong about that). Since part of the point of
PEP 384 is to support multiple versions of the C runtime in a single
process, relying on Windows-specific or post-C89 options  seems
unnecessary when there are platform neutral C89 compatible approaches
that achieve the same end in a way that will be completely obvious to
most C programmers.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From solipsis at pitrou.net  Sun Aug 29 23:43:49 2010
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sun, 29 Aug 2010 23:43:49 +0200
Subject: [Python-Dev] PEP 384 status
In-Reply-To: <AANLkTi=GXRQKObnou5mbS2kZ25Axics7Jr+KiuePveg_@mail.gmail.com>
References: <4C78DF1A.1060601@v.loewis.de>
	<AANLkTimwkay5v6uUhXPtvPA94DfCBNvWd-2MVFPYZD0q@mail.gmail.com>
	<4C795B06.1010903@v.loewis.de>
	<AANLkTi=3TsqFCUvy623UCQSxRzq5DcW=xMikiod4bFcx@mail.gmail.com>
	<20100829102447.115448f2@pitrou.net>
	<AANLkTikp+UW4dQZ-MZQ2ZDcVGSY2CVkvjgyxLA0V-FqQ@mail.gmail.com>
	<20100829111043.4d786fe6@pitrou.net>
	<AANLkTimoTeQODqxqwhnLKVj6E1YG9g_+UaNtuV_nUZ0C@mail.gmail.com>
	<20100829174314.7129953a@pitrou.net>
	<AANLkTi=GXRQKObnou5mbS2kZ25Axics7Jr+KiuePveg_@mail.gmail.com>
Message-ID: <20100829234349.50cdcabf@pitrou.net>

On Mon, 30 Aug 2010 07:31:34 +1000
Nick Coghlan <ncoghlan at gmail.com> wrote:
> Since part of the point of
> PEP 384 is to support multiple versions of the C runtime in a single
> process, [...]

I think that's quite a maximalist goal. The point of PEP 384 should be
to define a standard API for Python, (hopefully) spanning multiple
versions. Whether the API effectively guarantees a standard ABI can
only depend on whether the system itself hasn't changed its own
conventions (including, for example, function call conventions, or the
binary representation of standard C types).

In other words, PEP 384 should only care to stabilize the ABI as
long as the underlying system doesn't change. It sounds a bit foolish
for us to try to hide potential unstabilities in the underlying
platform. And it's equally foolish to try to forbid people from using
well-known system facilities such as FILE* or (worse) errno.

So, perhaps the C API docs can simply mention the caveat of using FILE*
(and perhaps errno, if there's a problem there as well) for C extensions
under Windows. C extension writers are (usually) consenting adults, for
all.

Regards

Antoine.

From g.rodola at gmail.com  Mon Aug 30 00:52:05 2010
From: g.rodola at gmail.com (=?ISO-8859-1?Q?Giampaolo_Rodol=E0?=)
Date: Mon, 30 Aug 2010 00:52:05 +0200
Subject: [Python-Dev] r84355 - python/branches/py3k/Lib/test/test_ssl.py
In-Reply-To: <4C7AD05D.2030102@voidspace.org.uk>
References: <20100829205656.59639EE99A@mail.python.org>
	<20100829232312.760b8214@pitrou.net>
	<4C7AD05D.2030102@voidspace.org.uk>
Message-ID: <AANLkTi=+4SNxUNjSnZ_q_VxAMQufWT4pcMzM+n5nH4NS@mail.gmail.com>

Sorry, I didn't get how the context-manager actually worked.
Fixed in r84356.

2010/8/29 Michael Foord <fuzzyman at voidspace.org.uk>:
> ?On 30/08/2010 00:23, Antoine Pitrou wrote:
>>
>> On Sun, 29 Aug 2010 22:56:56 +0200 (CEST)
>> giampaolo.rodola<python-checkins at python.org> ?wrote:
>>>
>>> + ? ? ? ?with self.assertRaises(IOError) as err:
>>> + ? ? ? ? ? ?ssl.wrap_socket(socket.socket(), certfile=WRONGCERT)
>>> + ? ? ? ? ? ?self.assertEqual(err.errno, errno.ENOENT)
>>
>> The assertEqual will never get executed since the previous line raises.
>
> If it is dedented once then it will work (in Python 2.7 / 3.2).
>
> Michael
>>>
>>> + ? ? ? ?with self.assertRaises(IOError) as err:
>>> + ? ? ? ? ? ?ssl.wrap_socket(socket.socket(), certfile=WRONGCERT,
>>> keyfile=WRONGCERT)
>>> + ? ? ? ? ? ?self.assertEqual(err.errno, errno.ENOENT)
>>
>> Same here.
>>
>>
>> _______________________________________________
>> Python-Dev mailing list
>> Python-Dev at 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 at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/g.rodola%40gmail.com
>

From cournape at gmail.com  Mon Aug 30 05:16:52 2010
From: cournape at gmail.com (David Cournapeau)
Date: Mon, 30 Aug 2010 12:16:52 +0900
Subject: [Python-Dev] PEP 384 status
In-Reply-To: <20100829234349.50cdcabf@pitrou.net>
References: <4C78DF1A.1060601@v.loewis.de>
	<AANLkTimwkay5v6uUhXPtvPA94DfCBNvWd-2MVFPYZD0q@mail.gmail.com>
	<4C795B06.1010903@v.loewis.de>
	<AANLkTi=3TsqFCUvy623UCQSxRzq5DcW=xMikiod4bFcx@mail.gmail.com>
	<20100829102447.115448f2@pitrou.net>
	<AANLkTikp+UW4dQZ-MZQ2ZDcVGSY2CVkvjgyxLA0V-FqQ@mail.gmail.com>
	<20100829111043.4d786fe6@pitrou.net>
	<AANLkTimoTeQODqxqwhnLKVj6E1YG9g_+UaNtuV_nUZ0C@mail.gmail.com>
	<20100829174314.7129953a@pitrou.net>
	<AANLkTi=GXRQKObnou5mbS2kZ25Axics7Jr+KiuePveg_@mail.gmail.com>
	<20100829234349.50cdcabf@pitrou.net>
Message-ID: <AANLkTi=5_e8AqboqE-Sg+HkjFDbXKAOfs+F1SfLrBuPh@mail.gmail.com>

On Mon, Aug 30, 2010 at 6:43 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Mon, 30 Aug 2010 07:31:34 +1000
> Nick Coghlan <ncoghlan at gmail.com> wrote:
>> Since part of the point of
>> PEP 384 is to support multiple versions of the C runtime in a single
>> process, [...]
>
> I think that's quite a maximalist goal. The point of PEP 384 should be
> to define a standard API for Python, (hopefully) spanning multiple
> versions. Whether the API effectively guarantees a standard ABI can
> only depend on whether the system itself hasn't changed its own
> conventions (including, for example, function call conventions, or the
> binary representation of standard C types).
>
> In other words, PEP 384 should only care to stabilize the ABI as
> long as the underlying system doesn't change. It sounds a bit foolish
> for us to try to hide potential unstabilities in the underlying
> platform. And it's equally foolish to try to forbid people from using
> well-known system facilities such as FILE* or (worse) errno.
>
> So, perhaps the C API docs can simply mention the caveat of using FILE*
> (and perhaps errno, if there's a problem there as well) for C extensions
> under Windows. C extension writers are (usually) consenting adults, for
> all.

This significantly decrease the value of such an API, to the point of
making it useless on windows, since historically different python
versions are built with different runtimes. And I would think that
windows is the platform where PEP 384 would be the most useful - at
least it would for numpy/scipy, where those runtimes issues have
bitten us several times (and are painful to debug, especially when you
don't know windows so well).

cheers,

David

From ncoghlan at gmail.com  Mon Aug 30 14:18:43 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 30 Aug 2010 22:18:43 +1000
Subject: [Python-Dev] PEP 384 status
In-Reply-To: <20100829234349.50cdcabf@pitrou.net>
References: <4C78DF1A.1060601@v.loewis.de>
	<AANLkTimwkay5v6uUhXPtvPA94DfCBNvWd-2MVFPYZD0q@mail.gmail.com>
	<4C795B06.1010903@v.loewis.de>
	<AANLkTi=3TsqFCUvy623UCQSxRzq5DcW=xMikiod4bFcx@mail.gmail.com>
	<20100829102447.115448f2@pitrou.net>
	<AANLkTikp+UW4dQZ-MZQ2ZDcVGSY2CVkvjgyxLA0V-FqQ@mail.gmail.com>
	<20100829111043.4d786fe6@pitrou.net>
	<AANLkTimoTeQODqxqwhnLKVj6E1YG9g_+UaNtuV_nUZ0C@mail.gmail.com>
	<20100829174314.7129953a@pitrou.net>
	<AANLkTi=GXRQKObnou5mbS2kZ25Axics7Jr+KiuePveg_@mail.gmail.com>
	<20100829234349.50cdcabf@pitrou.net>
Message-ID: <AANLkTi=8y6qDaJxxry85P3g2Nh5CBVyk6+xjRJyq1_bE@mail.gmail.com>

On Mon, Aug 30, 2010 at 7:43 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Mon, 30 Aug 2010 07:31:34 +1000
> Nick Coghlan <ncoghlan at gmail.com> wrote:
>> Since part of the point of
>> PEP 384 is to support multiple versions of the C runtime in a single
>> process, [...]
>
> I think that's quite a maximalist goal. The point of PEP 384 should be
> to define a standard API for Python, (hopefully) spanning multiple
> versions. Whether the API effectively guarantees a standard ABI can
> only depend on whether the system itself hasn't changed its own
> conventions (including, for example, function call conventions, or the
> binary representation of standard C types).

FILE* is very different from the other things you mention. Function
call conventions and binary representations are defined in the C
standard. FILE*, on the other hand, is explicitly called out as an
opaque reference completely under the control of the specific C
runtime implementation.

Since the Linkage section of PEP 384 specifically states the
availability of a generic "python3.dll" that dynamically redirects to
the relevant "python3y.dll" to allow an extension module to run
against any 3.2 or later Python version as a goal of the PEP, I would
say that allowing mixing of C runtimes is definitely one of the PEP's
goals.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From solipsis at pitrou.net  Mon Aug 30 14:26:24 2010
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 30 Aug 2010 14:26:24 +0200
Subject: [Python-Dev] PEP 384 status
In-Reply-To: <AANLkTi=8y6qDaJxxry85P3g2Nh5CBVyk6+xjRJyq1_bE@mail.gmail.com>
References: <4C78DF1A.1060601@v.loewis.de>
	<AANLkTimwkay5v6uUhXPtvPA94DfCBNvWd-2MVFPYZD0q@mail.gmail.com>
	<4C795B06.1010903@v.loewis.de>
	<AANLkTi=3TsqFCUvy623UCQSxRzq5DcW=xMikiod4bFcx@mail.gmail.com>
	<20100829102447.115448f2@pitrou.net>
	<AANLkTikp+UW4dQZ-MZQ2ZDcVGSY2CVkvjgyxLA0V-FqQ@mail.gmail.com>
	<20100829111043.4d786fe6@pitrou.net>
	<AANLkTimoTeQODqxqwhnLKVj6E1YG9g_+UaNtuV_nUZ0C@mail.gmail.com>
	<20100829174314.7129953a@pitrou.net>
	<AANLkTi=GXRQKObnou5mbS2kZ25Axics7Jr+KiuePveg_@mail.gmail.com>
	<20100829234349.50cdcabf@pitrou.net>
	<AANLkTi=8y6qDaJxxry85P3g2Nh5CBVyk6+xjRJyq1_bE@mail.gmail.com>
Message-ID: <1283171184.3248.2.camel@localhost.localdomain>

Le lundi 30 ao?t 2010 ? 22:18 +1000, Nick Coghlan a ?crit :
> 
> FILE* is very different from the other things you mention. Function
> call conventions and binary representations are defined in the C
> standard. FILE*, on the other hand, is explicitly called out as an
> opaque reference completely under the control of the specific C
> runtime implementation.
> 
> Since the Linkage section of PEP 384 specifically states the
> availability of a generic "python3.dll" that dynamically redirects to
> the relevant "python3y.dll" to allow an extension module to run
> against any 3.2 or later Python version as a goal of the PEP, I would
> say that allowing mixing of C runtimes is definitely one of the PEP's
> goals.

Well, allowing it is one thing. Guaranteeing that it will always work is
another one.
That said, I have nothing against Python providing such a guarantee, as
long as it doesn't complicate the work of developers on other platforms
who don't care about Windows.

Regards

Antoine.



From barry at python.org  Mon Aug 30 16:30:13 2010
From: barry at python.org (Barry Warsaw)
Date: Mon, 30 Aug 2010 10:30:13 -0400
Subject: [Python-Dev] PEP 384 status
In-Reply-To: <AANLkTi=GXRQKObnou5mbS2kZ25Axics7Jr+KiuePveg_@mail.gmail.com>
References: <4C78DF1A.1060601@v.loewis.de>
	<AANLkTimwkay5v6uUhXPtvPA94DfCBNvWd-2MVFPYZD0q@mail.gmail.com>
	<4C795B06.1010903@v.loewis.de>
	<AANLkTi=3TsqFCUvy623UCQSxRzq5DcW=xMikiod4bFcx@mail.gmail.com>
	<20100829102447.115448f2@pitrou.net>
	<AANLkTikp+UW4dQZ-MZQ2ZDcVGSY2CVkvjgyxLA0V-FqQ@mail.gmail.com>
	<20100829111043.4d786fe6@pitrou.net>
	<AANLkTimoTeQODqxqwhnLKVj6E1YG9g_+UaNtuV_nUZ0C@mail.gmail.com>
	<20100829174314.7129953a@pitrou.net>
	<AANLkTi=GXRQKObnou5mbS2kZ25Axics7Jr+KiuePveg_@mail.gmail.com>
Message-ID: <20100830103013.07309a2f@heresy>

On Aug 30, 2010, at 07:31 AM, Nick Coghlan wrote:

>Since part of the point of PEP 384 is to support multiple versions of the C
>runtime in a single process

Is it?  That's certainly not explicit in the Rationale section of PEP 384.

It seems to me that the PEP is all about inoculating extension builders from
changes in Python's ABI across Python versions.  That's a worthy goal.  I'm
not sure the same can be said about allowing multiple versions of the C
runtime in a linked process.  But then I'm developing on Windows these days,
and I think for all practical purposes, it's a moot point on *nix.

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100830/06e7ba07/attachment.pgp>

From barry at python.org  Mon Aug 30 16:35:25 2010
From: barry at python.org (Barry Warsaw)
Date: Mon, 30 Aug 2010 10:35:25 -0400
Subject: [Python-Dev] PEP 384 status
In-Reply-To: <AANLkTi=8y6qDaJxxry85P3g2Nh5CBVyk6+xjRJyq1_bE@mail.gmail.com>
References: <4C78DF1A.1060601@v.loewis.de>
	<AANLkTimwkay5v6uUhXPtvPA94DfCBNvWd-2MVFPYZD0q@mail.gmail.com>
	<4C795B06.1010903@v.loewis.de>
	<AANLkTi=3TsqFCUvy623UCQSxRzq5DcW=xMikiod4bFcx@mail.gmail.com>
	<20100829102447.115448f2@pitrou.net>
	<AANLkTikp+UW4dQZ-MZQ2ZDcVGSY2CVkvjgyxLA0V-FqQ@mail.gmail.com>
	<20100829111043.4d786fe6@pitrou.net>
	<AANLkTimoTeQODqxqwhnLKVj6E1YG9g_+UaNtuV_nUZ0C@mail.gmail.com>
	<20100829174314.7129953a@pitrou.net>
	<AANLkTi=GXRQKObnou5mbS2kZ25Axics7Jr+KiuePveg_@mail.gmail.com>
	<20100829234349.50cdcabf@pitrou.net>
	<AANLkTi=8y6qDaJxxry85P3g2Nh5CBVyk6+xjRJyq1_bE@mail.gmail.com>
Message-ID: <20100830103525.71039548@heresy>

On Aug 30, 2010, at 10:18 PM, Nick Coghlan wrote:

>Since the Linkage section of PEP 384 specifically states the
>availability of a generic "python3.dll" that dynamically redirects to
>the relevant "python3y.dll" to allow an extension module to run
>against any 3.2 or later Python version as a goal of the PEP, I would
>say that allowing mixing of C runtimes is definitely one of the PEP's
>goals.

It should be explicit about that then, and provide detail about why the
runtime is relevant to Windows programmers (and probably not relevant in
practice for *nix programmers).

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100830/4e995c03/attachment.pgp>

From fuzzyman at voidspace.org.uk  Mon Aug 30 16:47:05 2010
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Mon, 30 Aug 2010 17:47:05 +0300
Subject: [Python-Dev] PEP 384 status
In-Reply-To: <20100830103525.71039548@heresy>
References: <4C78DF1A.1060601@v.loewis.de>	<AANLkTimwkay5v6uUhXPtvPA94DfCBNvWd-2MVFPYZD0q@mail.gmail.com>	<4C795B06.1010903@v.loewis.de>	<AANLkTi=3TsqFCUvy623UCQSxRzq5DcW=xMikiod4bFcx@mail.gmail.com>	<20100829102447.115448f2@pitrou.net>	<AANLkTikp+UW4dQZ-MZQ2ZDcVGSY2CVkvjgyxLA0V-FqQ@mail.gmail.com>	<20100829111043.4d786fe6@pitrou.net>	<AANLkTimoTeQODqxqwhnLKVj6E1YG9g_+UaNtuV_nUZ0C@mail.gmail.com>	<20100829174314.7129953a@pitrou.net>	<AANLkTi=GXRQKObnou5mbS2kZ25Axics7Jr+KiuePveg_@mail.gmail.com>	<20100829234349.50cdcabf@pitrou.net>	<AANLkTi=8y6qDaJxxry85P3g2Nh5CBVyk6+xjRJyq1_bE@mail.gmail.com>
	<20100830103525.71039548@heresy>
Message-ID: <4C7BC469.2030109@voidspace.org.uk>

  On 30/08/2010 17:35, Barry Warsaw wrote:
> On Aug 30, 2010, at 10:18 PM, Nick Coghlan wrote:
>
>> Since the Linkage section of PEP 384 specifically states the
>> availability of a generic "python3.dll" that dynamically redirects to
>> the relevant "python3y.dll" to allow an extension module to run
>> against any 3.2 or later Python version as a goal of the PEP, I would
>> say that allowing mixing of C runtimes is definitely one of the PEP's
>> goals.
> It should be explicit about that then, and provide detail about why the
> runtime is relevant to Windows programmers (and probably not relevant in
> practice for *nix programmers).

An extension compiled for one version of Python will be linked against 
the version of the C runtime used by that version of Python (if it is 
compiled with the same version of Visual Studio of course).

If the extension binary is to remain compatible with a later version of 
Python, compiled against a different version of the C runtime, then it 
*must* be possible for multiple C runtimes to be loaded. If the stable 
ABI doesn't allow this then binaries will *still* have to be recompiled 
when we update the version of Visual Studio used to compile Python - 
defeating the purpose of the PEP. Right?

If this is the case then I agree that it should be explicit in the PEP.

All the best,

Michael

> -Barry
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at 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/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100830/981c5be7/attachment.html>

From barry at python.org  Mon Aug 30 20:10:08 2010
From: barry at python.org (Barry Warsaw)
Date: Mon, 30 Aug 2010 14:10:08 -0400
Subject: [Python-Dev] Released: Python 2.6.6
In-Reply-To: <i59gue$7ks$1@dough.gmane.org>
References: <20100824153146.69874f04@heresy> <20100824191240.1457a3f0@heresy>
	<4C74B23C.1010203@v.loewis.de> <4C7537A8.5070602@netwok.org>
	<i59gue$7ks$1@dough.gmane.org>
Message-ID: <20100830141008.20b672e7@heresy>

On Aug 28, 2010, at 01:12 AM, Georg Brandl wrote:

>I don't think I'll want to bother with porting doc fixes to the 2.6
>branch.

Thanks for the feedback everyone.  We will not be porting doc fixes to
release26-maint.  I would be open to a doc fix that was specifically
addressing a security concern, but we'll handle that the same way we handle
all security related fixes to retired branches.

Cheers,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100830/ed8fa9c2/attachment.pgp>

From barry at python.org  Mon Aug 30 20:35:16 2010
From: barry at python.org (Barry Warsaw)
Date: Mon, 30 Aug 2010 14:35:16 -0400
Subject: [Python-Dev] versioned .so files for Python 3.2
In-Reply-To: <4C78E4F0.9090306@v.loewis.de>
References: <20100624115048.4fd152e3@heresy>
	<AANLkTikrQiXeGtStA7BjHeda7m0XFwdbUHapzReA4UuD@mail.gmail.com>
	<20100714195955.4815f980@heresy> <4C40372C.9030101@ubuntu.com>
	<20100722164036.7a80d27c@snowdog>
	<AANLkTinqPksuOBXxqt7TyfNFZh8oAqqF7hXfpcMjZ05r@mail.gmail.com>
	<20100724002509.0ad8d359@snowdog> <4C78E4F0.9090306@v.loewis.de>
Message-ID: <20100830143516.50504004@heresy>

On Aug 28, 2010, at 12:29 PM, Martin v. L?wis wrote:

>The intention is that there is indeed just one stable ABI, so one
>configuration is the supported one, and that should be the "default"
>build.
>
>As for the specific settings, my analysis would be this:
>- pydebug: not supported by the stable ABI, as it changes the layout
>  of PyObject, which is an exposed structure
>  More specifically: Py_DEBUG, Py_TRACEREFS and Py_REF_DEBUG are
>  all incompatible with the stable ABI
>- pymalloc: I fail to see the impact on the ABI. All allocator
>  macros become function calls under Py_LIMITED_API, otherwise,
>  there shouldn't be any need to have different versions of that.
>- wide-unicode: this is a tricky one. I'm tempted to say that the
>  stable ABI should always use a Py_UNICODE that matches the platform's
>  wchar_t. Alternative proposals are welcome.

Thanks Martin.  I have updated PEP 3149 with these thoughts, but I'll leave it
up to you to update PEP 384.

I haven't heard a peep since my last RFC on PEP 3149.  Guido, would you care
to pronounce on the PEP, or designate someone who can do so (remembering that
Martin is off-line for a while)?  If acceptable, I'd like to get this into the
tree before 3.2 alpha 2, currently scheduled for September 5.

Cheers,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100830/f81a8221/attachment.pgp>

From db3l.net at gmail.com  Mon Aug 30 21:56:52 2010
From: db3l.net at gmail.com (David Bolen)
Date: Mon, 30 Aug 2010 15:56:52 -0400
Subject: [Python-Dev] Windows buildbots MSVC RTL popups
Message-ID: <m2mxs3x4aj.fsf@valheru.db3l.homeip.net>

Since the recent history of my two Windows buildbots has turned ugly,
I figured I'd mention that they both (XP and Windows 7) have started
generating quite a few GUI C++ RTL runtime pop-up assertions, which
has been throwing a wrench into things until they get manually
cleared.  I first noticed them Sunday night but they were probably
there 24-48 hours at that point.  These are R6034 "An application has
made an attempt to load the C runtime library incorrectly"

I glanced through recent commits and I don't think I see anything
obviously related but was wondering if anyone who might have been
committing changes in the past few days might have an thought?  The
source filename is truncated in the dialog (what genius at MS thought
that would be the one field worth truncating?!) so I am not absolutely
sure if they are limited to a specific branch or not.

I've thrown on an autoit script to try to automatically acknowledge
these dialogs so hopefully the affected test runs will just fail
rather than timing out and blocking later runs.

-- David


From florent.xicluna at gmail.com  Mon Aug 30 22:47:28 2010
From: florent.xicluna at gmail.com (Florent Xicluna)
Date: Mon, 30 Aug 2010 22:47:28 +0200
Subject: [Python-Dev] Windows buildbots MSVC RTL popups
In-Reply-To: <m2mxs3x4aj.fsf@valheru.db3l.homeip.net>
References: <m2mxs3x4aj.fsf@valheru.db3l.homeip.net>
Message-ID: <AANLkTikLvGnkonEHLDvLhz8dP+-kGdcNVhJ_aUbgYPCU@mail.gmail.com>

With the help of bbreport, I collected these informations:
 - 3 tests are freezing randomly : test_bz2, test_codecs and test_tarfile
 - it happens on XP-4 and Windows7 builders (branches 2.7 and 3.1
only, trunk is not affected)
 - it seems to happen since revisions 84345 and 84346 which fixed issue # 1868

my .2 cents,

-- 
Florent Xicluna

2010/8/30 David Bolen <db3l.net at gmail.com>:
> Since the recent history of my two Windows buildbots has turned ugly,
> I figured I'd mention that they both (XP and Windows 7) have started
> generating quite a few GUI C++ RTL runtime pop-up assertions, which
> has been throwing a wrench into things until they get manually
> cleared. ?I first noticed them Sunday night but they were probably
> there 24-48 hours at that point. ?These are R6034 "An application has
> made an attempt to load the C runtime library incorrectly"
>
> I glanced through recent commits and I don't think I see anything
> obviously related but was wondering if anyone who might have been
> committing changes in the past few days might have an thought? ?The
> source filename is truncated in the dialog (what genius at MS thought
> that would be the one field worth truncating?!) so I am not absolutely
> sure if they are limited to a specific branch or not.
>
> I've thrown on an autoit script to try to automatically acknowledge
> these dialogs so hopefully the affected test runs will just fail
> rather than timing out and blocking later runs.
>
> -- David

From ncoghlan at gmail.com  Mon Aug 30 23:17:17 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 31 Aug 2010 07:17:17 +1000
Subject: [Python-Dev] PEP 384 status
In-Reply-To: <20100830103013.07309a2f@heresy>
References: <4C78DF1A.1060601@v.loewis.de>
	<AANLkTimwkay5v6uUhXPtvPA94DfCBNvWd-2MVFPYZD0q@mail.gmail.com>
	<4C795B06.1010903@v.loewis.de>
	<AANLkTi=3TsqFCUvy623UCQSxRzq5DcW=xMikiod4bFcx@mail.gmail.com>
	<20100829102447.115448f2@pitrou.net>
	<AANLkTikp+UW4dQZ-MZQ2ZDcVGSY2CVkvjgyxLA0V-FqQ@mail.gmail.com>
	<20100829111043.4d786fe6@pitrou.net>
	<AANLkTimoTeQODqxqwhnLKVj6E1YG9g_+UaNtuV_nUZ0C@mail.gmail.com>
	<20100829174314.7129953a@pitrou.net>
	<AANLkTi=GXRQKObnou5mbS2kZ25Axics7Jr+KiuePveg_@mail.gmail.com>
	<20100830103013.07309a2f@heresy>
Message-ID: <AANLkTimm0k4+Y_a0+mRxEC-w70N+2Mh3QkMkwJbHgSfZ@mail.gmail.com>

On Tue, Aug 31, 2010 at 12:30 AM, Barry Warsaw <barry at python.org> wrote:
> On Aug 30, 2010, at 07:31 AM, Nick Coghlan wrote:
>
>>Since part of the point of PEP 384 is to support multiple versions of the C
>>runtime in a single process
>
> Is it? ?That's certainly not explicit in the Rationale section of PEP 384.
>
> It seems to me that the PEP is all about inoculating extension builders from
> changes in Python's ABI across Python versions. ?That's a worthy goal. ?I'm
> not sure the same can be said about allowing multiple versions of the C
> runtime in a linked process. ?But then I'm developing on Windows these days,
> and I think for all practical purposes, it's a moot point on *nix.

Yeah, I found the Rationale section a little lacking in that regard as
well. It was more of a description of the status quo rather than an
attempt to justify the proposed changes. The actual proposal and
benefits were down in the Linkage section.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From ncoghlan at gmail.com  Mon Aug 30 23:54:16 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 31 Aug 2010 07:54:16 +1000
Subject: [Python-Dev] PEP 384 status
In-Reply-To: <4C7BC469.2030109@voidspace.org.uk>
References: <4C78DF1A.1060601@v.loewis.de>
	<AANLkTimwkay5v6uUhXPtvPA94DfCBNvWd-2MVFPYZD0q@mail.gmail.com>
	<4C795B06.1010903@v.loewis.de>
	<AANLkTi=3TsqFCUvy623UCQSxRzq5DcW=xMikiod4bFcx@mail.gmail.com>
	<20100829102447.115448f2@pitrou.net>
	<AANLkTikp+UW4dQZ-MZQ2ZDcVGSY2CVkvjgyxLA0V-FqQ@mail.gmail.com>
	<20100829111043.4d786fe6@pitrou.net>
	<AANLkTimoTeQODqxqwhnLKVj6E1YG9g_+UaNtuV_nUZ0C@mail.gmail.com>
	<20100829174314.7129953a@pitrou.net>
	<AANLkTi=GXRQKObnou5mbS2kZ25Axics7Jr+KiuePveg_@mail.gmail.com>
	<20100829234349.50cdcabf@pitrou.net>
	<AANLkTi=8y6qDaJxxry85P3g2Nh5CBVyk6+xjRJyq1_bE@mail.gmail.com>
	<20100830103525.71039548@heresy>
	<4C7BC469.2030109@voidspace.org.uk>
Message-ID: <AANLkTi=7h7W3r_bsz87x0vFOcFBnh9x8ZPSeHFkPnEwv@mail.gmail.com>

On Tue, Aug 31, 2010 at 12:47 AM, Michael Foord
<fuzzyman at voidspace.org.uk> wrote:
> An extension compiled for one version of Python will be linked against the
> version of the C runtime used by that version of Python (if it is compiled
> with the same version of Visual Studio of course).
>
> If the extension binary is to remain compatible with a later version of
> Python, compiled against a different version of the C runtime, then it
> *must* be possible for multiple C runtimes to be loaded. If the stable ABI
> doesn't allow this then binaries will *still* have to be recompiled when we
> update the version of Visual Studio used to compile Python - defeating the
> purpose of the PEP. Right?
>
> If this is the case then I agree that it should be explicit in the PEP.

Ah, I knew it was explicit in the PEP somewhere. The following is
currently mentioned in the "Excluded Functions" section:

"In addition, functions expecting FILE* are not part of the ABI, to
avoid depending on a specific version of the Microsoft C runtime DLL
on Windows."

To make that explicit in the Rationale section, I would append a
second sentence to the final paragraph of that section (the first
sentence is already there):

"With this PEP, it will be possible to reduce the dependency of binary
extension modules on a specific Python feature release, and
applications embedding Python can be made work with different
releases. To ensure this is also achieved on Windows, the ABI will be
designed to allow the Python binary and extension modules or an
embedding application to depend on different versions of the C runtime
DLL."

I would also make the following modification to the above quoted
paragraph from the Excluded Functions section of the PEP:

"To avoid depending on a specific version of the Microsoft C runtime
DLL on Windows while still providing a consistent, cross-platform API
when PY_LIMITED_API is defined, the following functions are also
excluded:
- Any functions accepting or returning FILE* (as this is defined in
the C standard as an implementation dependent opaque reference. On
Windows, it is known to contain reference to runtime-specific global
data)
- Any functions reliant on global or thread local state expected to be
modified by C standard library calls rather than other Python API
calls (e.g. PyErr_FromErrno will be unavailable. Comparable
functionality will be provided by a new function PyErr_FromErrnoEx,
with the latter accepting an explicit errno parameter)

Where practical, equivalent functionality for the excluded functions
will instead be provided using preprocessor macros. This ensures that
the use of the C runtime dependent types and data remains separate
without significantly complicating extension module development and
the API remains compatible with any C89 compiler.

Note that locale dependent operations will still be available, they
just may not see locale changes made via the C standard library calls.
Locale changes will need to be made via Python API calls to the locale
module to ensure they are seen correctly by the interpreter."

Hmm... that last point is a bit of any issue actually, since it also
flows the other way (changes made via the locale module won't be
visible to any extension modules using a different C runtime). So I
suspect mixing C runtimes is still going to come with the caveat of
potential locale related glitches.

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia

From cournape at gmail.com  Tue Aug 31 04:12:17 2010
From: cournape at gmail.com (David Cournapeau)
Date: Tue, 31 Aug 2010 11:12:17 +0900
Subject: [Python-Dev] PEP 384 status
In-Reply-To: <AANLkTi=7h7W3r_bsz87x0vFOcFBnh9x8ZPSeHFkPnEwv@mail.gmail.com>
References: <4C78DF1A.1060601@v.loewis.de>
	<AANLkTimwkay5v6uUhXPtvPA94DfCBNvWd-2MVFPYZD0q@mail.gmail.com>
	<4C795B06.1010903@v.loewis.de>
	<AANLkTi=3TsqFCUvy623UCQSxRzq5DcW=xMikiod4bFcx@mail.gmail.com>
	<20100829102447.115448f2@pitrou.net>
	<AANLkTikp+UW4dQZ-MZQ2ZDcVGSY2CVkvjgyxLA0V-FqQ@mail.gmail.com>
	<20100829111043.4d786fe6@pitrou.net>
	<AANLkTimoTeQODqxqwhnLKVj6E1YG9g_+UaNtuV_nUZ0C@mail.gmail.com>
	<20100829174314.7129953a@pitrou.net>
	<AANLkTi=GXRQKObnou5mbS2kZ25Axics7Jr+KiuePveg_@mail.gmail.com>
	<20100829234349.50cdcabf@pitrou.net>
	<AANLkTi=8y6qDaJxxry85P3g2Nh5CBVyk6+xjRJyq1_bE@mail.gmail.com>
	<20100830103525.71039548@heresy>
	<4C7BC469.2030109@voidspace.org.uk>
	<AANLkTi=7h7W3r_bsz87x0vFOcFBnh9x8ZPSeHFkPnEwv@mail.gmail.com>
Message-ID: <AANLkTika2ZcN9No+fopGnuTyDu4AHxwW6gE=qhxH9_VN@mail.gmail.com>

On Tue, Aug 31, 2010 at 6:54 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:


> Hmm... that last point is a bit of any issue actually, since it also
> flows the other way (changes made via the locale module won't be
> visible to any extension modules using a different C runtime). So I
> suspect mixing C runtimes is still going to come with the caveat of
> potential locale related glitches.

As far as IO is concerned, FILE* is just a special case of a more
generic issue, though, so maybe this could be a bit reworded. For
example, file descriptor cannot be shared between runtimes either.

cheers,

David

From skippy.hammond at gmail.com  Tue Aug 31 06:15:42 2010
From: skippy.hammond at gmail.com (Mark Hammond)
Date: Tue, 31 Aug 2010 14:15:42 +1000
Subject: [Python-Dev] PEP 384 status
In-Reply-To: <AANLkTi=7h7W3r_bsz87x0vFOcFBnh9x8ZPSeHFkPnEwv@mail.gmail.com>
References: <4C78DF1A.1060601@v.loewis.de>	<AANLkTimwkay5v6uUhXPtvPA94DfCBNvWd-2MVFPYZD0q@mail.gmail.com>	<4C795B06.1010903@v.loewis.de>	<AANLkTi=3TsqFCUvy623UCQSxRzq5DcW=xMikiod4bFcx@mail.gmail.com>	<20100829102447.115448f2@pitrou.net>	<AANLkTikp+UW4dQZ-MZQ2ZDcVGSY2CVkvjgyxLA0V-FqQ@mail.gmail.com>	<20100829111043.4d786fe6@pitrou.net>	<AANLkTimoTeQODqxqwhnLKVj6E1YG9g_+UaNtuV_nUZ0C@mail.gmail.com>	<20100829174314.7129953a@pitrou.net>	<AANLkTi=GXRQKObnou5mbS2kZ25Axics7Jr+KiuePveg_@mail.gmail.com>	<20100829234349.50cdcabf@pitrou.net>	<AANLkTi=8y6qDaJxxry85P3g2Nh5CBVyk6+xjRJyq1_bE@mail.gmail.com>	<20100830103525.71039548@heresy>	<4C7BC469.2030109@voidspace.org.uk>
	<AANLkTi=7h7W3r_bsz87x0vFOcFBnh9x8ZPSeHFkPnEwv@mail.gmail.com>
Message-ID: <4C7C81EE.8050303@gmail.com>

On 31/08/2010 7:54 AM, Nick Coghlan wrote:
> On Tue, Aug 31, 2010 at 12:47 AM, Michael Foord
> <fuzzyman at voidspace.org.uk>  wrote:
>> An extension compiled for one version of Python will be linked against the
>> version of the C runtime used by that version of Python (if it is compiled
>> with the same version of Visual Studio of course).
>>
>> If the extension binary is to remain compatible with a later version of
>> Python, compiled against a different version of the C runtime, then it
>> *must* be possible for multiple C runtimes to be loaded. If the stable ABI
>> doesn't allow this then binaries will *still* have to be recompiled when we
>> update the version of Visual Studio used to compile Python - defeating the
>> purpose of the PEP. Right?
>>
>> If this is the case then I agree that it should be explicit in the PEP.
>
> Ah, I knew it was explicit in the PEP somewhere. The following is
> currently mentioned in the "Excluded Functions" section:
>
> "In addition, functions expecting FILE* are not part of the ABI, to
> avoid depending on a specific version of the Microsoft C runtime DLL
> on Windows."

It would be interesting to know how, in practice, these FILE pointers 
come to life.  In my experience they are generally obtained via fopen. 
If that is broadly true, then a middle-ground may be for Python to 
expose something like Py_fopen, Py_fclose and a PyFILE opaque "handle". 
  API elements which currently take a FILE * could be exposed using a 
PyFILE * in the ABI.  People who didn't care about this level of 
portability could continue to use the non-ABI FILE * functions, but 
people who do could use Py_fopen/Py_fclose in place of fopen/fclose but 
otherwise work as now.

A downside is that as mentioned, in practice these FILE pointers may 
come from more than simply fopen, so few people would be able to 
leverage this.  It also assumes that people open files before handing 
them to Python, but otherwise don't use that file - it would be a 
slippery-slope to wind up with Py_fread etc.

Mark

From techtonik at gmail.com  Tue Aug 31 08:49:41 2010
From: techtonik at gmail.com (anatoly techtonik)
Date: Tue, 31 Aug 2010 09:49:41 +0300
Subject: [Python-Dev] Internal counter to debug leaking file descriptors
Message-ID: <AANLkTi=5=nXdoBM5RqxVZ1gKcokwdBZSk49Rqua2WJc5@mail.gmail.com>

Hi,

Is there any kind of internal file descriptor counter that can be
queried to debug issues with leaking resources?
It can be used in tests to check that all tests are finish with 0
opened descriptors.
It will be very useful while porting Python applications from Unix to
Windows. Unix is more tolerant to open files and can overwrite them
and do other nasty things. See the thread from comment #17 -
https://bugs.edge.launchpad.net/dulwich/+bug/557585/ - there is an
example of mmap that starts holding file descriptor somewhere long
before an error occurs. How could one debug this?

Right now I have to use FileMon. It includes information about
operated filenames, but no info about source code where this happens.
It will be nice to have some kind of counter with filename information
inside Python, so that it can be possible to get the full log of
events without manually messing with external system-specific tools
like FileMon.

--
anatoly t.

From ronaldoussoren at mac.com  Tue Aug 31 10:32:27 2010
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Tue, 31 Aug 2010 10:32:27 +0200
Subject: [Python-Dev] versioned .so files for Python 3.2
In-Reply-To: <4C78E4F0.9090306@v.loewis.de>
References: <20100624115048.4fd152e3@heresy>
	<AANLkTikrQiXeGtStA7BjHeda7m0XFwdbUHapzReA4UuD@mail.gmail.com>
	<20100714195955.4815f980@heresy> <4C40372C.9030101@ubuntu.com>
	<20100722164036.7a80d27c@snowdog>
	<AANLkTinqPksuOBXxqt7TyfNFZh8oAqqF7hXfpcMjZ05r@mail.gmail.com>
	<20100724002509.0ad8d359@snowdog> <4C78E4F0.9090306@v.loewis.de>
Message-ID: <7BA45755-EF5F-4A4E-9E47-21C9A80C29B4@mac.com>


On 28 Aug, 2010, at 12:29, Martin v. L?wis wrote:
> 
> - wide-unicode: this is a tricky one. I'm tempted to say that the
>  stable ABI should always use a Py_UNICODE that matches the platform's
>  wchar_t. Alternative proposals are welcome.

Sizeof(wchar_t) is 4 on OSX, but the Apple frameworks use a 16-bit type to represent unicode codepoints (UniChar).  Current builds on OSX use a 16-bit unicode type which makes it pretty cheap to convert strings from Python to a C array of UniChar.

I'm therefore -1 on switching to a wide unicode build on OSX. 

Ronald

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3567 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100831/a806a84e/attachment.bin>

From solipsis at pitrou.net  Tue Aug 31 10:51:00 2010
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Tue, 31 Aug 2010 10:51:00 +0200
Subject: [Python-Dev] PEP 384 status
References: <4C78DF1A.1060601@v.loewis.de>
	<AANLkTimwkay5v6uUhXPtvPA94DfCBNvWd-2MVFPYZD0q@mail.gmail.com>
	<4C795B06.1010903@v.loewis.de>
	<AANLkTi=3TsqFCUvy623UCQSxRzq5DcW=xMikiod4bFcx@mail.gmail.com>
	<20100829102447.115448f2@pitrou.net>
	<AANLkTikp+UW4dQZ-MZQ2ZDcVGSY2CVkvjgyxLA0V-FqQ@mail.gmail.com>
	<20100829111043.4d786fe6@pitrou.net>
	<AANLkTimoTeQODqxqwhnLKVj6E1YG9g_+UaNtuV_nUZ0C@mail.gmail.com>
	<20100829174314.7129953a@pitrou.net>
	<AANLkTi=GXRQKObnou5mbS2kZ25Axics7Jr+KiuePveg_@mail.gmail.com>
	<20100829234349.50cdcabf@pitrou.net>
	<AANLkTi=8y6qDaJxxry85P3g2Nh5CBVyk6+xjRJyq1_bE@mail.gmail.com>
	<20100830103525.71039548@heresy>
	<4C7BC469.2030109@voidspace.org.uk>
	<AANLkTi=7h7W3r_bsz87x0vFOcFBnh9x8ZPSeHFkPnEwv@mail.gmail.com>
	<AANLkTika2ZcN9No+fopGnuTyDu4AHxwW6gE=qhxH9_VN@mail.gmail.com>
Message-ID: <20100831105100.68f7e718@pitrou.net>

On Tue, 31 Aug 2010 11:12:17 +0900
David Cournapeau <cournape at gmail.com> wrote:
> 
> > Hmm... that last point is a bit of any issue actually, since it also
> > flows the other way (changes made via the locale module won't be
> > visible to any extension modules using a different C runtime). So I
> > suspect mixing C runtimes is still going to come with the caveat of
> > potential locale related glitches.
> 
> As far as IO is concerned, FILE* is just a special case of a more
> generic issue, though, so maybe this could be a bit reworded. For
> example, file descriptor cannot be shared between runtimes either.

Er, really?
So it means that, for example, a FileIO object couldn't be shared
between runtimes either? How about a socket object?
Do you want to forbid FileIO and socket objects as part of the API?

Again, I propose that FILE* functions are allowed in the API, but their
use discouraged in the docs (with proper explanations from those who
know how to word them).

Regards

Antoine.



From mal at egenix.com  Tue Aug 31 11:22:53 2010
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue, 31 Aug 2010 11:22:53 +0200
Subject: [Python-Dev] versioned .so files for Python 3.2
In-Reply-To: <7BA45755-EF5F-4A4E-9E47-21C9A80C29B4@mac.com>
References: <20100624115048.4fd152e3@heresy>	<AANLkTikrQiXeGtStA7BjHeda7m0XFwdbUHapzReA4UuD@mail.gmail.com>	<20100714195955.4815f980@heresy>
	<4C40372C.9030101@ubuntu.com>	<20100722164036.7a80d27c@snowdog>	<AANLkTinqPksuOBXxqt7TyfNFZh8oAqqF7hXfpcMjZ05r@mail.gmail.com>	<20100724002509.0ad8d359@snowdog>
	<4C78E4F0.9090306@v.loewis.de>
	<7BA45755-EF5F-4A4E-9E47-21C9A80C29B4@mac.com>
Message-ID: <4C7CC9ED.9090405@egenix.com>

Ronald Oussoren wrote:
> 
> On 28 Aug, 2010, at 12:29, Martin v. L?wis wrote:
>>
>> - wide-unicode: this is a tricky one. I'm tempted to say that the
>>  stable ABI should always use a Py_UNICODE that matches the platform's
>>  wchar_t. Alternative proposals are welcome.
> 
> Sizeof(wchar_t) is 4 on OSX, but the Apple frameworks use a 16-bit type to represent unicode codepoints (UniChar).  Current builds on OSX use a 16-bit unicode type which makes it pretty cheap to convert strings from Python to a C array of UniChar.
> 
> I'm therefore -1 on switching to a wide unicode build on OSX. 

-1 on always using wchar_t as well. Python's default is UCS2
and the stable ABI should not change that.

I also think that this information is not relevant for the
stable ABI: Extensions that want to stick to the stable ABI
should really not have to know whether Py_UNICODE maps to
wchar_t or not. If they want to interface to a local whcar_t
type they can use the conversion APIs we have for that in the
Unicode API: PyUnicode_FromWideChar() and PyUnicode_AsWideChar().

BTW: Wasn't one of the main reasons for having versioned .so files
the idea to be able to have UCS2 and UCS4 versions installed
side-by-side ?

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Aug 27 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-08-19: Released mxODBC 3.1.0              http://python.egenix.com/
2010-09-15: DZUG Tagung, Dresden, Germany                  18 days to go

::: 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/

From mal at egenix.com  Tue Aug 31 11:54:51 2010
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue, 31 Aug 2010 11:54:51 +0200
Subject: [Python-Dev] PEP 384 status
In-Reply-To: <4C7BC469.2030109@voidspace.org.uk>
References: <4C78DF1A.1060601@v.loewis.de>	<AANLkTimwkay5v6uUhXPtvPA94DfCBNvWd-2MVFPYZD0q@mail.gmail.com>	<4C795B06.1010903@v.loewis.de>	<AANLkTi=3TsqFCUvy623UCQSxRzq5DcW=xMikiod4bFcx@mail.gmail.com>	<20100829102447.115448f2@pitrou.net>	<AANLkTikp+UW4dQZ-MZQ2ZDcVGSY2CVkvjgyxLA0V-FqQ@mail.gmail.com>	<20100829111043.4d786fe6@pitrou.net>	<AANLkTimoTeQODqxqwhnLKVj6E1YG9g_+UaNtuV_nUZ0C@mail.gmail.com>	<20100829174314.7129953a@pitrou.net>	<AANLkTi=GXRQKObnou5mbS2kZ25Axics7Jr+KiuePveg_@mail.gmail.com>	<20100829234349.50cdcabf@pitrou.net>	<AANLkTi=8y6qDaJxxry85P3g2Nh5CBVyk6+xjRJyq1_bE@mail.gmail.com>	<20100830103525.71039548@heresy>
	<4C7BC469.2030109@voidspace.org.uk>
Message-ID: <4C7CD16B.1000604@egenix.com>

Michael Foord wrote:
>  On 30/08/2010 17:35, Barry Warsaw wrote:
>> On Aug 30, 2010, at 10:18 PM, Nick Coghlan wrote:
>>
>>> Since the Linkage section of PEP 384 specifically states the
>>> availability of a generic "python3.dll" that dynamically redirects to
>>> the relevant "python3y.dll" to allow an extension module to run
>>> against any 3.2 or later Python version as a goal of the PEP, I would
>>> say that allowing mixing of C runtimes is definitely one of the PEP's
>>> goals.
>> It should be explicit about that then, and provide detail about why the
>> runtime is relevant to Windows programmers (and probably not relevant in
>> practice for *nix programmers).
> 
> An extension compiled for one version of Python will be linked against
> the version of the C runtime used by that version of Python (if it is
> compiled with the same version of Visual Studio of course).
> 
> If the extension binary is to remain compatible with a later version of
> Python, compiled against a different version of the C runtime, then it
> *must* be possible for multiple C runtimes to be loaded. 

Is it possible to have multiple versions of the lib C loaded
on Windows ?

I know that it is not possible on Linux. Instead, the glibc takes great
care to version all sorts of APIs in the lib to make it possible
to run applications using different versions  within the same runtime
(they include different ABI versions in the same lib).

AFAIK, on Windows, the lib C is using a different approach: up until
the invention of the manifests, they took great care not to break
the APIs in incompatible ways.

With manifests, things are more complicated, since the DLLs now
explicitly reference a particular version of a DLL (down to the
patch level) and if the versions are not installed, the application
won't run. Not sure what effect that has on the way they engineered
the new lib C versions...

This document suggests that it is possible to have an application
use multiple CRTs, but care has to be taken with respect to
things that are initialized by the CRTs (env vars, locales,
handles, etc.):

http://msdn.microsoft.com/en-us/library/abx4dbyh(v=VS.90).aspx

> If the stable
> ABI doesn't allow this then binaries will *still* have to be recompiled
> when we update the version of Visual Studio used to compile Python -
> defeating the purpose of the PEP. Right?

If we keep changing the main compiler version used for creating
Python binaries on Windows: yes. Fortunately, we don't :-)

On Unix this shouldn't be too much of a problem, though, so the
PEP is still valid for those platforms.

> If this is the case then I agree that it should be explicit in the PEP.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Aug 27 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-08-19: Released mxODBC 3.1.0              http://python.egenix.com/
2010-09-15: DZUG Tagung, Dresden, Germany                  18 days to go

::: 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/

From amauryfa at gmail.com  Tue Aug 31 11:56:10 2010
From: amauryfa at gmail.com (Amaury Forgeot d'Arc)
Date: Tue, 31 Aug 2010 11:56:10 +0200
Subject: [Python-Dev] PEP 384 status
In-Reply-To: <20100831105100.68f7e718@pitrou.net>
References: <4C78DF1A.1060601@v.loewis.de>
	<AANLkTimwkay5v6uUhXPtvPA94DfCBNvWd-2MVFPYZD0q@mail.gmail.com>
	<4C795B06.1010903@v.loewis.de>
	<AANLkTi=3TsqFCUvy623UCQSxRzq5DcW=xMikiod4bFcx@mail.gmail.com>
	<20100829102447.115448f2@pitrou.net>
	<AANLkTikp+UW4dQZ-MZQ2ZDcVGSY2CVkvjgyxLA0V-FqQ@mail.gmail.com>
	<20100829111043.4d786fe6@pitrou.net>
	<AANLkTimoTeQODqxqwhnLKVj6E1YG9g_+UaNtuV_nUZ0C@mail.gmail.com>
	<20100829174314.7129953a@pitrou.net>
	<AANLkTi=GXRQKObnou5mbS2kZ25Axics7Jr+KiuePveg_@mail.gmail.com>
	<20100829234349.50cdcabf@pitrou.net>
	<AANLkTi=8y6qDaJxxry85P3g2Nh5CBVyk6+xjRJyq1_bE@mail.gmail.com>
	<20100830103525.71039548@heresy>
	<4C7BC469.2030109@voidspace.org.uk>
	<AANLkTi=7h7W3r_bsz87x0vFOcFBnh9x8ZPSeHFkPnEwv@mail.gmail.com>
	<AANLkTika2ZcN9No+fopGnuTyDu4AHxwW6gE=qhxH9_VN@mail.gmail.com>
	<20100831105100.68f7e718@pitrou.net>
Message-ID: <AANLkTinKseNHp8eoC3C_s+Ju0kmwZPrjgdSE4ym_PWOh@mail.gmail.com>

Hi,

2010/8/31 Antoine Pitrou <solipsis at pitrou.net>:
> David Cournapeau <cournape at gmail.com> wrote:
>> As far as IO is concerned, FILE* is just a special case of a more
>> generic issue, though, so maybe this could be a bit reworded. For
>> example, file descriptor cannot be shared between runtimes either.
>
> Er, really?

Yes, on Windows, file descriptors returned by open() or dup() cannot be shared
between runtimes. What can be safely shared is the underlying "handle",
you can get it with the _get_osfhandle() function.

> So it means that, for example, a FileIO object couldn't be shared
> between runtimes either? How about a socket object?
> Do you want to forbid FileIO and socket objects as part of the API?

Python objects don't have this concern: all methods of FileIO are implemented
in a single file (fileio.c), linked to a single C runtime.

> Again, I propose that FILE* functions are allowed in the API, but their
> use discouraged in the docs (with proper explanations from those who
> know how to word them).

IMO the warnings you'd write there would be similar to the motivations of
PEP 384.

-- 
Amaury Forgeot d'Arc

From solipsis at pitrou.net  Tue Aug 31 12:03:13 2010
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Tue, 31 Aug 2010 12:03:13 +0200
Subject: [Python-Dev] PEP 384 status
In-Reply-To: <AANLkTinKseNHp8eoC3C_s+Ju0kmwZPrjgdSE4ym_PWOh@mail.gmail.com>
References: <4C78DF1A.1060601@v.loewis.de>
	<AANLkTimwkay5v6uUhXPtvPA94DfCBNvWd-2MVFPYZD0q@mail.gmail.com>
	<4C795B06.1010903@v.loewis.de>
	<AANLkTi=3TsqFCUvy623UCQSxRzq5DcW=xMikiod4bFcx@mail.gmail.com>
	<20100829102447.115448f2@pitrou.net>
	<AANLkTikp+UW4dQZ-MZQ2ZDcVGSY2CVkvjgyxLA0V-FqQ@mail.gmail.com>
	<20100829111043.4d786fe6@pitrou.net>
	<AANLkTimoTeQODqxqwhnLKVj6E1YG9g_+UaNtuV_nUZ0C@mail.gmail.com>
	<20100829174314.7129953a@pitrou.net>
	<AANLkTi=GXRQKObnou5mbS2kZ25Axics7Jr+KiuePveg_@mail.gmail.com>
	<20100829234349.50cdcabf@pitrou.net>
	<AANLkTi=8y6qDaJxxry85P3g2Nh5CBVyk6+xjRJyq1_bE@mail.gmail.com>
	<20100830103525.71039548@heresy> <4C7BC469.2030109@voidspace.org.uk>
	<AANLkTi=7h7W3r_bsz87x0vFOcFBnh9x8ZPSeHFkPnEwv@mail.gmail.com>
	<AANLkTika2ZcN9No+fopGnuTyDu4AHxwW6gE=qhxH9_VN@mail.gmail.com>
	<20100831105100.68f7e718@pitrou.net>
	<AANLkTinKseNHp8eoC3C_s+Ju0kmwZPrjgdSE4ym_PWOh@mail.gmail.com>
Message-ID: <1283248993.3226.16.camel@localhost.localdomain>


> > So it means that, for example, a FileIO object couldn't be shared
> > between runtimes either? How about a socket object?
> > Do you want to forbid FileIO and socket objects as part of the API?
> 
> Python objects don't have this concern: all methods of FileIO are implemented
> in a single file (fileio.c), linked to a single C runtime.

Ah, right. But you still can call the fileno() method.

Regards

Antoine.



From nyamatongwe at gmail.com  Tue Aug 31 13:04:28 2010
From: nyamatongwe at gmail.com (Neil Hodgson)
Date: Tue, 31 Aug 2010 21:04:28 +1000
Subject: [Python-Dev] PEP 384 status
In-Reply-To: <4C7CD16B.1000604@egenix.com>
References: <4C78DF1A.1060601@v.loewis.de>
	<AANLkTimwkay5v6uUhXPtvPA94DfCBNvWd-2MVFPYZD0q@mail.gmail.com>
	<4C795B06.1010903@v.loewis.de>
	<AANLkTi=3TsqFCUvy623UCQSxRzq5DcW=xMikiod4bFcx@mail.gmail.com>
	<20100829102447.115448f2@pitrou.net>
	<AANLkTikp+UW4dQZ-MZQ2ZDcVGSY2CVkvjgyxLA0V-FqQ@mail.gmail.com>
	<20100829111043.4d786fe6@pitrou.net>
	<AANLkTimoTeQODqxqwhnLKVj6E1YG9g_+UaNtuV_nUZ0C@mail.gmail.com>
	<20100829174314.7129953a@pitrou.net>
	<AANLkTi=GXRQKObnou5mbS2kZ25Axics7Jr+KiuePveg_@mail.gmail.com>
	<20100829234349.50cdcabf@pitrou.net>
	<AANLkTi=8y6qDaJxxry85P3g2Nh5CBVyk6+xjRJyq1_bE@mail.gmail.com>
	<20100830103525.71039548@heresy>
	<4C7BC469.2030109@voidspace.org.uk> <4C7CD16B.1000604@egenix.com>
Message-ID: <AANLkTinCJXm-rAERgqzpgnFaJ8VvUh5rpzxi+bNmt=-a@mail.gmail.com>

M.-A. Lemburg:

> Is it possible to have multiple versions of the lib C loaded
> on Windows ?

   Yes. It is possible not only to mix C runtimes from different
vendors but different variants from a single vendor.

   Historically, each vendor has shipped their own C runtime
libraries. This was also the case with CP/M and OS/2.

   Many applications can be extended with DLLs and if it were not
possible to load DLLs which use different runtimes then that would
limit which compilers can be used to extend particular applications.
If Microsoft were to stop DLLs compiled with Borland or Intel from
working inside Internet Explorer or Excel then there would be
considerable controversy and likely anti-trust actions.

   Neil

From barry at python.org  Tue Aug 31 15:55:17 2010
From: barry at python.org (Barry Warsaw)
Date: Tue, 31 Aug 2010 09:55:17 -0400
Subject: [Python-Dev] versioned .so files for Python 3.2
In-Reply-To: <4C7CC9ED.9090405@egenix.com>
References: <20100624115048.4fd152e3@heresy>
	<AANLkTikrQiXeGtStA7BjHeda7m0XFwdbUHapzReA4UuD@mail.gmail.com>
	<20100714195955.4815f980@heresy> <4C40372C.9030101@ubuntu.com>
	<20100722164036.7a80d27c@snowdog>
	<AANLkTinqPksuOBXxqt7TyfNFZh8oAqqF7hXfpcMjZ05r@mail.gmail.com>
	<20100724002509.0ad8d359@snowdog> <4C78E4F0.9090306@v.loewis.de>
	<7BA45755-EF5F-4A4E-9E47-21C9A80C29B4@mac.com>
	<4C7CC9ED.9090405@egenix.com>
Message-ID: <20100831095517.1d3fb4b5@heresy>

On Aug 31, 2010, at 11:22 AM, M.-A. Lemburg wrote:

>BTW: Wasn't one of the main reasons for having versioned .so files
>the idea to be able to have UCS2 and UCS4 versions installed
>side-by-side ?

Yes.  This isn't an issue for PEP 3149 because it adds a flag to the shared
library file name for wide unicodes.  It's an issue for PEP 384.

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100831/1b02706f/attachment.pgp>

From guido at python.org  Tue Aug 31 16:03:46 2010
From: guido at python.org (Guido van Rossum)
Date: Tue, 31 Aug 2010 07:03:46 -0700
Subject: [Python-Dev] Internal counter to debug leaking file descriptors
In-Reply-To: <AANLkTi=5=nXdoBM5RqxVZ1gKcokwdBZSk49Rqua2WJc5@mail.gmail.com>
References: <AANLkTi=5=nXdoBM5RqxVZ1gKcokwdBZSk49Rqua2WJc5@mail.gmail.com>
Message-ID: <AANLkTin_NWyarJiVkEus6wWhsiwq6--Vq51COrG6tuvx@mail.gmail.com>

If you wanted to do something like this in the Python stdlib, you'd
have to monkey-patch (with a proxy/wrapper) all places that can open
or close a filedescriptor -- os.open, os.popen, os.close, file
open/close, socket open/close, and probably a bunch more that I've
forgotten. Also some extension modules may open file descriptors
directly through the C interfaces.

I don't know if the Windows libc has some kind of tracking feature for
file descriptors; of course it complicates things by using separate
(numeric) namespaces for sockets and files.

On Linux you can look somewhere in /proc, but I don't know that it
would help you find where a file was opened.

--Guido

On Mon, Aug 30, 2010 at 11:49 PM, anatoly techtonik <techtonik at gmail.com> wrote:
> Hi,
>
> Is there any kind of internal file descriptor counter that can be
> queried to debug issues with leaking resources?
> It can be used in tests to check that all tests are finish with 0
> opened descriptors.
> It will be very useful while porting Python applications from Unix to
> Windows. Unix is more tolerant to open files and can overwrite them
> and do other nasty things. See the thread from comment #17 -
> https://bugs.edge.launchpad.net/dulwich/+bug/557585/ - there is an
> example of mmap that starts holding file descriptor somewhere long
> before an error occurs. How could one debug this?
>
> Right now I have to use FileMon. It includes information about
> operated filenames, but no info about source code where this happens.
> It will be nice to have some kind of counter with filename information
> inside Python, so that it can be possible to get the full log of
> events without manually messing with external system-specific tools
> like FileMon.
>
> --
> anatoly t.
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org
>



-- 
--Guido van Rossum (python.org/~guido)

From glyph at twistedmatrix.com  Tue Aug 31 19:22:22 2010
From: glyph at twistedmatrix.com (Glyph Lefkowitz)
Date: Tue, 31 Aug 2010 13:22:22 -0400
Subject: [Python-Dev] Internal counter to debug leaking file descriptors
In-Reply-To: <AANLkTin_NWyarJiVkEus6wWhsiwq6--Vq51COrG6tuvx@mail.gmail.com>
References: <AANLkTi=5=nXdoBM5RqxVZ1gKcokwdBZSk49Rqua2WJc5@mail.gmail.com>
	<AANLkTin_NWyarJiVkEus6wWhsiwq6--Vq51COrG6tuvx@mail.gmail.com>
Message-ID: <A2BCE86D-68A6-477F-BD40-0885ADF9BD91@twistedmatrix.com>


On Aug 31, 2010, at 10:03 AM, Guido van Rossum wrote:

> On Linux you can look somewhere in /proc, but I don't know that it
> would help you find where a file was opened.

"/dev/fd" is actually a somewhat portable way of getting this information.  I don't think it's part of a standard, but on Linux it's usually a symlink to "/proc/self/fd", and it's available on MacOS and most BSDs (based on a hasty and completely-not-comprehensive investigation).  But it won't help you find out when the FDs were originally opened, no.

From exarkun at twistedmatrix.com  Tue Aug 31 19:40:31 2010
From: exarkun at twistedmatrix.com (exarkun at twistedmatrix.com)
Date: Tue, 31 Aug 2010 17:40:31 -0000
Subject: [Python-Dev] Internal counter to debug leaking file descriptors
In-Reply-To: <A2BCE86D-68A6-477F-BD40-0885ADF9BD91@twistedmatrix.com>
References: <AANLkTi=5=nXdoBM5RqxVZ1gKcokwdBZSk49Rqua2WJc5@mail.gmail.com>
	<AANLkTin_NWyarJiVkEus6wWhsiwq6--Vq51COrG6tuvx@mail.gmail.com>
	<A2BCE86D-68A6-477F-BD40-0885ADF9BD91@twistedmatrix.com>
Message-ID: <20100831174031.2058.1538356427.divmod.xquotient.168@localhost.localdomain>

On 05:22 pm, glyph at twistedmatrix.com wrote:
>
>On Aug 31, 2010, at 10:03 AM, Guido van Rossum wrote:
>>On Linux you can look somewhere in /proc, but I don't know that it
>>would help you find where a file was opened.
>
>"/dev/fd" is actually a somewhat portable way of getting this 
>information.  I don't think it's part of a standard, but on Linux it's 
>usually a symlink to "/proc/self/fd", and it's available on MacOS and 
>most BSDs (based on a hasty and completely-not-comprehensive 
>investigation).  But it won't help you find out when the FDs were 
>originally opened, no.
>_______________________________________________

On OS X and Solaris, dtrace and ustack will tell you exactly when and 
where the FDs were originally opened, though.  On Linux, SystemTap might 
give you the same information (but I know much less about SystemTap). 
If http://bugs.python.org/issue4111 is resolved, then this may even be 
possible without using a patched version of Python.

Jean-Paul

From dmalcolm at redhat.com  Tue Aug 31 20:39:52 2010
From: dmalcolm at redhat.com (David Malcolm)
Date: Tue, 31 Aug 2010 14:39:52 -0400
Subject: [Python-Dev] Internal counter to debug leaking file descriptors
In-Reply-To: <20100831174031.2058.1538356427.divmod.xquotient.168@localhost.localdomain>
References: <AANLkTi=5=nXdoBM5RqxVZ1gKcokwdBZSk49Rqua2WJc5@mail.gmail.com>
	<AANLkTin_NWyarJiVkEus6wWhsiwq6--Vq51COrG6tuvx@mail.gmail.com>
	<A2BCE86D-68A6-477F-BD40-0885ADF9BD91@twistedmatrix.com>
	<20100831174031.2058.1538356427.divmod.xquotient.168@localhost.localdomain>
Message-ID: <1283279992.12547.49.camel@radiator.bos.redhat.com>


On Tue, 2010-08-31 at 17:40 +0000, exarkun at twistedmatrix.com wrote:
> On 05:22 pm, glyph at twistedmatrix.com wrote:
> >
> >On Aug 31, 2010, at 10:03 AM, Guido van Rossum wrote:
> >>On Linux you can look somewhere in /proc, but I don't know that it
> >>would help you find where a file was opened.
> >
> >"/dev/fd" is actually a somewhat portable way of getting this 
> >information.  I don't think it's part of a standard, but on Linux it's 
> >usually a symlink to "/proc/self/fd", and it's available on MacOS and 
> >most BSDs (based on a hasty and completely-not-comprehensive 
> >investigation).  But it won't help you find out when the FDs were 
> >originally opened, no.
> >_______________________________________________
> 
> On OS X and Solaris, dtrace and ustack will tell you exactly when and 
> where the FDs were originally opened, though.  On Linux, SystemTap might 
> give you the same information (but I know much less about SystemTap). 
> If http://bugs.python.org/issue4111 is resolved, then this may even be 
> possible without using a patched version of Python.

I believe you can do something like this:
$ cat /tmp/trace-all-syscalls.stp 
/*
  Watch all syscalls in a specified process, dumping a user-space
  backtrace 
*/
probe syscall.* {
  if (pid() == target()) {
      printf("%s(%s)\n", probefunc(), argstr)
      print_ubacktrace();
  }
}

$ sudo stap --ldd -d /usr/bin/python /tmp/trace-all-syscalls.stp -c "python -c 'print 42'"

This generates a torrent of debug data like this:
sys_mmap_pgoff(0x0, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
 0x38f44e17aa : mmap64+0xa/0x30 [libc-2.11.90.so]
 0x38f44673fc : _IO_file_doallocate+0x7c/0x110 [libc-2.11.90.so]
 0x38f447498c : _IO_doallocbuf+0x2c/0x50 [libc-2.11.90.so]
 0x38f4472ef4 : _IO_file_underflow@@GLIBC_2.2.5+0x1b4/0x230 [libc-2.11.90.so]
 0x38f44749ce : _IO_default_uflow+0xe/0x30 [libc-2.11.90.so]
 0x38f446fdcb : getc+0xab/0xf0 [libc-2.11.90.so]
 0x39054f3e13 : r_long+0x23/0x120 [libpython2.6.so.1.0]
 0x39054f3f3b : PyMarshal_ReadLongFromFile+0x2b/0x30 [libpython2.6.so.1.0]
 0x39054f0661 : load_source_module+0x271/0x640 [libpython2.6.so.1.0]
 0x39054f1cc5 : import_submodule+0x155/0x300 [libpython2.6.so.1.0]
 0x39054f1f85 : load_next+0x115/0x2a0 [libpython2.6.so.1.0]
 0x39054f2592 : import_module_level+0x212/0x730 [libpython2.6.so.1.0]
 0x39054f3314 : PyImport_ImportModuleLevel+0x44/0xb0 [libpython2.6.so.1.0]
 0x39054d843f : builtin___import__+0x8f/0xa0 [libpython2.6.so.1.0]
 0x3905443f43 : PyObject_Call+0x53/0x100 [libpython2.6.so.1.0]
 0x39054d89b3 : PyEval_CallObjectWithKeywords+0x43/0xf0 [libpython2.6.so.1.0]
 0x39054db674 : PyEval_EvalFrameEx+0x21b4/0x65b0 [libpython2.6.so.1.0]
 0x39054e03a8 : PyEval_EvalCodeEx+0x938/0x9e0 [libpython2.6.so.1.0]
 0x39054e0482 : PyEval_EvalCode+0x32/0x40 [libpython2.6.so.1.0]
 0x39054f02c2 : PyImport_ExecCodeModuleEx+0xc2/0x1f0 [libpython2.6.so.1.0]
 0x39054f07a6 : load_source_module+0x3b6/0x640 [libpython2.6.so.1.0]


You may want to specify specific syscalls in the above to narrow the
scope.

Issue 4111 patches cpython to statically mark Python frame entry/exit so
that systemtap can directly instrument that; in Fedora 13 onwards I've
built Python with systemtap hooks so that you can add:

probe python.function.entry {
    printf("%s:%s:%d\n", filename, funcname, lineno);
}


(Arguably this is wrong, it's frame entry/exit, rather than function
entry/exit).

Potentially systemtap could be taught how to decipher/prettyprint Python
backtraces in a similar way to how gdb does it (by hooking into
PyEval_EvalFrameEx)


Hope this is helpful
Dave


From daniel at stutzbachenterprises.com  Tue Aug 31 21:36:00 2010
From: daniel at stutzbachenterprises.com (Daniel Stutzbach)
Date: Tue, 31 Aug 2010 14:36:00 -0500
Subject: [Python-Dev] PEP 384 status
In-Reply-To: <4C7CD16B.1000604@egenix.com>
References: <4C78DF1A.1060601@v.loewis.de>
	<AANLkTimwkay5v6uUhXPtvPA94DfCBNvWd-2MVFPYZD0q@mail.gmail.com>
	<4C795B06.1010903@v.loewis.de>
	<AANLkTi=3TsqFCUvy623UCQSxRzq5DcW=xMikiod4bFcx@mail.gmail.com>
	<20100829102447.115448f2@pitrou.net>
	<AANLkTikp+UW4dQZ-MZQ2ZDcVGSY2CVkvjgyxLA0V-FqQ@mail.gmail.com>
	<20100829111043.4d786fe6@pitrou.net>
	<AANLkTimoTeQODqxqwhnLKVj6E1YG9g_+UaNtuV_nUZ0C@mail.gmail.com>
	<20100829174314.7129953a@pitrou.net>
	<AANLkTi=GXRQKObnou5mbS2kZ25Axics7Jr+KiuePveg_@mail.gmail.com>
	<20100829234349.50cdcabf@pitrou.net>
	<AANLkTi=8y6qDaJxxry85P3g2Nh5CBVyk6+xjRJyq1_bE@mail.gmail.com>
	<20100830103525.71039548@heresy>
	<4C7BC469.2030109@voidspace.org.uk> <4C7CD16B.1000604@egenix.com>
Message-ID: <AANLkTimX7acdZ0TbNE0z9d6=KQSVCodaxs7+2sYmRG7o@mail.gmail.com>

On Tue, Aug 31, 2010 at 4:54 AM, M.-A. Lemburg <mal at egenix.com> wrote:

> Is it possible to have multiple versions of the lib C loaded
> on Windows ?
>

Yes, and it's a pretty common situation.   The fopen() that I call within a
DLL may not be the same fopen() called by another DLL.  When writing a DLL
for Windows, the API must be designed with the assumption that anything
returned by the C library cannot be passed a different C library.  For
example, suppose I a expose a function in my DLL that allocates some memory,
populates it with useful information, and returns a pointer.  I must also
supply a function to free the memory.  I cannot ask the caller to simply
call free(), because their free() may not be using the same heap as my
malloc().

Likewise, a FILE * isn't safe to pass around, unless I can guarantee that
the application really is one big happy family compiled against the same
version of the C library.
--
Daniel Stutzbach, Ph.D.
President, Stutzbach Enterprises, LLC <http://stutzbachenterprises.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100831/d3259ac1/attachment.html>

From mal at egenix.com  Tue Aug 31 23:49:40 2010
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue, 31 Aug 2010 23:49:40 +0200
Subject: [Python-Dev] PEP 384 status
In-Reply-To: <AANLkTimX7acdZ0TbNE0z9d6=KQSVCodaxs7+2sYmRG7o@mail.gmail.com>
References: <4C78DF1A.1060601@v.loewis.de>	<AANLkTimwkay5v6uUhXPtvPA94DfCBNvWd-2MVFPYZD0q@mail.gmail.com>	<4C795B06.1010903@v.loewis.de>	<AANLkTi=3TsqFCUvy623UCQSxRzq5DcW=xMikiod4bFcx@mail.gmail.com>	<20100829102447.115448f2@pitrou.net>	<AANLkTikp+UW4dQZ-MZQ2ZDcVGSY2CVkvjgyxLA0V-FqQ@mail.gmail.com>	<20100829111043.4d786fe6@pitrou.net>	<AANLkTimoTeQODqxqwhnLKVj6E1YG9g_+UaNtuV_nUZ0C@mail.gmail.com>	<20100829174314.7129953a@pitrou.net>	<AANLkTi=GXRQKObnou5mbS2kZ25Axics7Jr+KiuePveg_@mail.gmail.com>	<20100829234349.50cdcabf@pitrou.net>	<AANLkTi=8y6qDaJxxry85P3g2Nh5CBVyk6+xjRJyq1_bE@mail.gmail.com>	<20100830103525.71039548@heresy>	<4C7BC469.2030109@voidspace.org.uk>
	<4C7CD16B.1000604@egenix.com>
	<AANLkTimX7acdZ0TbNE0z9d6=KQSVCodaxs7+2sYmRG7o@mail.gmail.com>
Message-ID: <4C7D78F4.9040900@egenix.com>

Daniel Stutzbach wrote:
> On Tue, Aug 31, 2010 at 4:54 AM, M.-A. Lemburg <mal at egenix.com> wrote:
> 
>> Is it possible to have multiple versions of the lib C loaded
>> on Windows ?
>>
> 
> Yes, and it's a pretty common situation.   The fopen() that I call within a
> DLL may not be the same fopen() called by another DLL.  When writing a DLL
> for Windows, the API must be designed with the assumption that anything
> returned by the C library cannot be passed a different C library.  For
> example, suppose I a expose a function in my DLL that allocates some memory,
> populates it with useful information, and returns a pointer.  I must also
> supply a function to free the memory.  I cannot ask the caller to simply
> call free(), because their free() may not be using the same heap as my
> malloc().

But isn't exactly that a major problem for Python ?

An extension written for a different MS CRT version would
not be able to safely free a buffer allocated by the Python
DLL.

> Likewise, a FILE * isn't safe to pass around, unless I can guarantee that
> the application really is one big happy family compiled against the same
> version of the C library.

According to the MS document I found this also applies to the OS
environment and handles.

Taking all these things together makes it sound like there's
a rather small chance of actually getting PEP 384 working
across Windows compiler upgrades.

Then again, I haven't heard of many people actually running into
those possible issues.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Aug 27 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-08-19: Released mxODBC 3.1.0              http://python.egenix.com/
2010-09-15: DZUG Tagung, Dresden, Germany                  18 days to go

::: 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/

From mal at egenix.com  Tue Aug 31 23:52:10 2010
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue, 31 Aug 2010 23:52:10 +0200
Subject: [Python-Dev] PEP 384 status
In-Reply-To: <AANLkTinCJXm-rAERgqzpgnFaJ8VvUh5rpzxi+bNmt=-a@mail.gmail.com>
References: <4C78DF1A.1060601@v.loewis.de>	<AANLkTimwkay5v6uUhXPtvPA94DfCBNvWd-2MVFPYZD0q@mail.gmail.com>	<4C795B06.1010903@v.loewis.de>	<AANLkTi=3TsqFCUvy623UCQSxRzq5DcW=xMikiod4bFcx@mail.gmail.com>	<20100829102447.115448f2@pitrou.net>	<AANLkTikp+UW4dQZ-MZQ2ZDcVGSY2CVkvjgyxLA0V-FqQ@mail.gmail.com>	<20100829111043.4d786fe6@pitrou.net>	<AANLkTimoTeQODqxqwhnLKVj6E1YG9g_+UaNtuV_nUZ0C@mail.gmail.com>	<20100829174314.7129953a@pitrou.net>	<AANLkTi=GXRQKObnou5mbS2kZ25Axics7Jr+KiuePveg_@mail.gmail.com>	<20100829234349.50cdcabf@pitrou.net>	<AANLkTi=8y6qDaJxxry85P3g2Nh5CBVyk6+xjRJyq1_bE@mail.gmail.com>	<20100830103525.71039548@heresy>	<4C7BC469.2030109@voidspace.org.uk>
	<4C7CD16B.1000604@egenix.com>
	<AANLkTinCJXm-rAERgqzpgnFaJ8VvUh5rpzxi+bNmt=-a@mail.gmail.com>
Message-ID: <4C7D798A.3040200@egenix.com>

Neil Hodgson wrote:
> M.-A. Lemburg:
> 
>> Is it possible to have multiple versions of the lib C loaded
>> on Windows ?
> 
>    Yes. It is possible not only to mix C runtimes from different
> vendors but different variants from a single vendor.
> 
>    Historically, each vendor has shipped their own C runtime
> libraries. This was also the case with CP/M and OS/2.
> 
>    Many applications can be extended with DLLs and if it were not
> possible to load DLLs which use different runtimes then that would
> limit which compilers can be used to extend particular applications.
> If Microsoft were to stop DLLs compiled with Borland or Intel from
> working inside Internet Explorer or Excel then there would be
> considerable controversy and likely anti-trust actions.

Thanks for the feedback.

This sounds like the issues such a mix can cause are mostly
theoretical and don't really bother much in practice, so
PEP 384 on Windows does have a chance :-)

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Aug 27 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-08-19: Released mxODBC 3.1.0              http://python.egenix.com/
2010-09-15: DZUG Tagung, Dresden, Germany                  18 days to go

::: 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/