On Sun, Aug 1, 2010 at 1:25 PM, Greg Ewing 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 fina
On Sun, 01 Aug 2010 13:01:32 +1200
Greg Ewing 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
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 ra
On Sun, Aug 1, 2010 at 11:00 AM, Brian Curtin 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
On Sun, Aug 1, 2010 at 11:01 AM, Greg Ewing 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 cl
On Sat, Jul 31, 2010 at 19:48, Mark Lawrence 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, a
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
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python
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
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 p
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
>>On Sat, 31 Jul 2010 07:44:42 am Guido van Rossum wrote:
>>> http://docs.python.org/reference/lexical_analysis.html#reserved-classes-of-identifiers
> On Jul 31, 2010, at 08:32 AM, Steven D'Aprano wrote:
>>I have a small concern about the wording of that, specifically this:
>>
>>"System-defined na
>> Note that the PEP 376 implementation is mainly done in pkgutil. A
>> custom version lives in distutils2 but
>> when ready, will be pushed independently in pkgutil
>
> Ok. It would be helpful for unittest2 (the backport) if it was *still*
> available in distutils2 even after the merge into pkgu
On Jul 31, 2010, at 12:45 AM, Georg Brandl wrote:
>to warm up for tomorrow's 3.2alpha1 release, I did a mini-sprint on
>pdb issues today. I'm pleased to report that 14 issues could be
>closed, and pdb got a range of small new features, such as commands on
>the command line, "until " or "longlist"
On Jul 30, 2010, at 05:23 PM, Eric Snow wrote:
>First appeared in docs for 2.6 (October 02, 2008). Not sure if that
>is when it first because constrained this way.
>
>http://docs.python.org/library/constants.html?highlight=__debug__#__debug__
Thanks Eric, this is probably the right section of th
On Jul 31, 2010, at 08:32 AM, Steven D'Aprano wrote:
>On Sat, 31 Jul 2010 07:44:42 am Guido van Rossum wrote:
>> On Fri, Jul 30, 2010 at 1:53 PM, Barry Warsaw
>wrote:
>> > On Jul 30, 2010, at 01:42 PM, Guido van Rossum wrote:
>> >>Well it is a reserved name so those packages that were setting it
On 31/07/2010 17:22, Tarek Ziadé wrote:
On Sat, Jul 31, 2010 at 1:46 PM, Michael Foord
wrote:
...
Installation of plugins would still be done through the standard
distutils(2) machinery. (Using PEP 376 would depend on distutils2. I would
be fine with this.)
Note that the PEP 376 imp
On Sat, Jul 31, 2010 at 1:46 PM, Michael Foord
wrote:
...
>
> Installation of plugins would still be done through the standard
> distutils(2) machinery. (Using PEP 376 would depend on distutils2. I would
> be fine with this.)
Note that the PEP 376 implementation is mainly done in pkgutil. A
custo
On Sun, Aug 1, 2010 at 1:36 AM, Michael Foord wrote:
> On 31/07/2010 16:30, Nick Coghlan wrote:
>> With my change, that code would work just fine. "from myproject.gizmo
>> import main" and "from __main__ import main" would just return the
>> same object, whereas currently they return something dif
On Sun, Aug 1, 2010 at 1:23 AM, Alexander Belopolsky
wrote:
> On Sat, Jul 31, 2010 at 11:07 AM, Nick Coghlan wrote:
> ..
>> That said, I really don't think catching such a rare error is worth
>> *any* runtime overhead. Just making "__main__" and the real module
>> name refer to the same object in
On 31/07/2010 16:30, Nick Coghlan wrote:
On Sun, Aug 1, 2010 at 1:14 AM, Michael Foord wrote:
Some people workaround the potential for bugs caused by __main__ reimporting
itself by doing it *deliberately*. Glyf even recommends it as good practise.
;-)
http://glyf.livejournal.com/60326.html
On Sun, Aug 1, 2010 at 1:14 AM, Michael Foord wrote:
> Some people workaround the potential for bugs caused by __main__ reimporting
> itself by doing it *deliberately*. Glyf even recommends it as good practise.
> ;-)
>
> http://glyf.livejournal.com/60326.html
>
> So - the fix you suggest would *br
On Sat, Jul 31, 2010 at 11:07 AM, Nick Coghlan wrote:
..
> That said, I really don't think catching such a rare error is worth
> *any* runtime overhead. Just making "__main__" and the real module
> name refer to the same object in sys.modules is a different matter,
> but I'm not confident enough t
On 31/07/2010 16:07, Nick Coghlan wrote:
On Sat, Jul 31, 2010 at 3:57 PM, Daniel Waterworth
wrote:
@Nick: I suppose the simplest way to detect re-importation in the
general case, is to store a set of hashes of files that have been
imported. When a user tries to import a file where it's has
On Sat, Jul 31, 2010 at 3:57 PM, Daniel Waterworth
wrote:
> @Nick: I suppose the simplest way to detect re-importation in the
> general case, is to store a set of hashes of files that have been
> imported. When a user tries to import a file where it's hash is
> already in the set, a warning is gen
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".
Michael
and use the PEP 376 metadata, in concert with a user config file, to
discover all plugins *available*. A plugins subcommand could then
a
On 31/07/2010 01:51, David Cournapeau wrote:
On Fri, Jul 30, 2010 at 10:23 PM, Michael Foord
wrote:
For those of you who found this document perhaps just a little bit too long,
I've written up a *much* shorter intro to the plugin system (including how
to get the prototype) on my blog:
26 matches
Mail list logo
