2010/7/31 David Cournapeau courn...@gmail.com:
On Fri, Jul 30, 2010 at 10:23 PM, Michael Foord
fuzzy...@voidspace.org.uk 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
On 31 July 2010 02:21, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
On Fri, Jul 30, 2010 at 2:46 PM, Daniel Waterworth
da.waterwo...@gmail.com wrote:
..
Having thought it through thoroughly, my preference is for a warning.
I don't think it's a good practise to import the
On 31/07/2010 01:51, David Cournapeau wrote:
On Fri, Jul 30, 2010 at 10:23 PM, Michael Foord
fuzzy...@voidspace.org.uk 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
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
On Sat, Jul 31, 2010 at 3:57 PM, Daniel Waterworth
da.waterwo...@gmail.com 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
On 31/07/2010 16:07, Nick Coghlan wrote:
On Sat, Jul 31, 2010 at 3:57 PM, Daniel Waterworth
da.waterwo...@gmail.com 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
On Sat, Jul 31, 2010 at 11:07 AM, Nick Coghlan ncogh...@gmail.com 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
On Sun, Aug 1, 2010 at 1:14 AM, Michael Foord fuzzy...@voidspace.org.uk 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
On 31/07/2010 16:30, Nick Coghlan wrote:
On Sun, Aug 1, 2010 at 1:14 AM, Michael Foordfuzzy...@voidspace.org.uk wrote:
Some people workaround the potential for bugs caused by __main__ reimporting
itself by doing it *deliberately*. Glyf even recommends it as good practise.
;-)
On Sun, Aug 1, 2010 at 1:23 AM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
On Sat, Jul 31, 2010 at 11:07 AM, Nick Coghlan ncogh...@gmail.com wrote:
..
That said, I really don't think catching such a rare error is worth
*any* runtime overhead. Just making __main__ and the real
On Sun, Aug 1, 2010 at 1:36 AM, Michael Foord fuzzy...@voidspace.org.uk 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
On Sat, Jul 31, 2010 at 1:46 PM, Michael Foord
fuzzy...@voidspace.org.uk 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
On 31/07/2010 17:22, Tarek Ziadé wrote:
On Sat, Jul 31, 2010 at 1:46 PM, Michael Foord
fuzzy...@voidspace.org.uk 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.)
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 ba...@python.org
wrote:
On Jul 30, 2010, at 01:42 PM, Guido van Rossum wrote:
Well it is a reserved name so those packages that were
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 the
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 lineno or longlist
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 pkgutil (for
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 names. These
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
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
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
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
On Sat, Jul 31, 2010 at 19:48, Mark Lawrence breamore...@yahoo.co.ukwrote:
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
On Sun, Aug 1, 2010 at 11:01 AM, Greg Ewing greg.ew...@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
On Sun, Aug 1, 2010 at 11:00 AM, Brian Curtin brian.cur...@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
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
On Sun, 01 Aug 2010 13:01:32 +1200
Greg Ewing greg.ew...@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
On Sun, Aug 1, 2010 at 1:25 PM, Greg Ewing greg.ew...@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
28 matches
Mail list logo
