On 31 July 2010 02:21, Alexander Belopolsky
wrote:
> On Fri, Jul 30, 2010 at 2:46 PM, Daniel Waterworth
> wrote:
> ..
>> Having thought it through thoroughly, my preference is for a warning.
>>
>> I don't think it's a good practise to import the __main__ module by
>> filename, as renaming the fil
2010/7/31 David Cournapeau :
> 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:
>>
>> http:
On Sat, Jul 31, 2010 at 12:34 AM, Michael Foord
wrote:
> Explicit registration over implicit registration by subclassing is an
> interesting discussion, but I like the simplicity provided by just
> subclassing.
Note that ABCs are deliberately designed to let *users* choose to do
either. Subclassi
On Fri, Jul 30, 2010 at 2:46 PM, Daniel Waterworth
wrote:
..
> Having thought it through thoroughly, my preference is for a warning.
>
> I don't think it's a good practise to import the __main__ module by
> filename, as renaming the file will break the code. I got stung after,
> having dropped int
On Sat, Jul 31, 2010 at 4:46 AM, Daniel Waterworth
wrote:
> Having thought it through thoroughly, my preference is for a warning.
That's actually harder than it sounds.
Inserting "__main__" into sys.modules under its normal name as well as
"__main__" is actually pretty easy (for both direct exec
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:
>
> http://www.voidspace.org.uk/python/weblog/a
On Fri, Jul 30, 2010 at 4:07 PM, Georg Brandl wrote:
> Am 31.07.2010 01:01, schrieb Guido van Rossum:
>> Warning: 'p' is *not* the same as 'print'. 'p' is a built-in command
>> that prints the expression's repr(). 'print' OTOH falls back through
>> the interpreter and executes a print statement or
Am 31.07.2010 01:01, schrieb Guido van Rossum:
> On Fri, Jul 30, 2010 at 3:45 PM, 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, suc
On Fri, Jul 30, 2010 at 3:45 PM, 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 "lo
Hi,
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" showing all the code for the
current function (th
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
> >>should have known that they were using undefined behav
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__
-eric
-Original Message-
From: python-dev-bounces+esnow=verio@python.org
[mailto:python-de
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
>>should have known that they were using undefined behavior that could
>>change at any time.
>
> Shouldn't it be descri
Love it!
BTW, it's not a good idea to have an import statement under 3
level of loops:
https://code.google.com/p/2to3-speedup2/source/browse/trunk/lib2to3/refactor.py#427
-- Alexandre
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python
2010/7/30 Barry Warsaw :
> 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
>>should have known that they were using undefined behavior that could
>>change at any time.
>
> Shouldn't it be described here then?
>
> http://doc
At 04:37 PM 7/30/2010 +0200, Tarek Ziadé wrote:
On Fri, Jul 30, 2010 at 4:04 PM, Barry Warsaw wrote:
..
> * Registration - How do third party plugins declare themselves to
exist, and
> be enabled? Part of this seems to me to include interface declarations
> too. Is installation of the plug
At 11:50 PM 7/30/2010 +0400, Oleg Broytman wrote:
On Fri, Jul 30, 2010 at 07:46:44PM +0100, Daniel Waterworth wrote:
> can anyone think of a case where someone has
> been annoyed that, having imported that same module twice via
> symlinks, they have had problems relating to modules being independ
On 30/07/2010 21:56, P.J. Eby wrote:
At 03:34 PM 7/30/2010 +0100, Michael Foord wrote:
Automatic discoverability, a-la setuptools entry points, is not
without its problems though. Tarek outlines some of these in a more
recent blog post:
FWIW, it's not discovery that's the problem, but configu
At 03:34 PM 7/30/2010 +0100, Michael Foord wrote:
Automatic discoverability, a-la setuptools entry points, is not
without its problems though. Tarek outlines some of these in a more
recent blog post:
FWIW, it's not discovery that's the problem, but configuring *which*
plugins you wish to have
On 30/07/2010 21:53, 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
should have known that they were using undefined behavior that could
change at any time.
Shouldn't it be described here the
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
>should have known that they were using undefined behavior that could
>change at any time.
Shouldn't it be described here then?
http://docs.python.org/reference/lexical_analys
Great! CS FTW!
--Guido
On Fri, Jul 30, 2010 at 1:28 PM, George Boutsioukis
wrote:
> Hi everyone, I haven't had a chance to introduce myself yet. I'm George
> Boutsioukis, a CS student from Greece and I'm currently enrolled as a GSOC
> student for the PSF. The task I was involved with for the pas
On Fri, Jul 30, 2010 at 1:26 PM, Barry Warsaw wrote:
> In working on making Python 2.7 available in Debian and Ubuntu, we ran into
> two packages that fail to byte compile against Python 2.7, where they are fine
> in Python 2.6. The Debian bug tracker issues are:
>
> http://bugs.debian.org/cgi
Hi everyone, I haven't had a chance to introduce myself yet. I'm George
Boutsioukis, a CS student from Greece and I'm currently enrolled as a GSOC
student for the PSF. The task I was involved with for the past few weeks was
speeding up the 2to3 tool.
For those who are not aware of 2to3's internal
In working on making Python 2.7 available in Debian and Ubuntu, we ran into
two packages that fail to byte compile against Python 2.7, where they are fine
in Python 2.6. The Debian bug tracker issues are:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=590821
http://bugs.debian.org/cgi-b
Hello all!
For those of you who use the Bazaar mirrors on Launchpad of the Python
Subversion branches (dvcs ftw! :), I've just registered the Python 2.7
maintenance branch. It will take a little while to complete the import, but
when it's done you can grab it with:
% bzr branch lp:python/2.7
On Fri, Jul 30, 2010 at 07:46:44PM +0100, Daniel Waterworth wrote:
> can anyone think of a case where someone has
> been annoyed that, having imported that same module twice via
> symlinks, they have had problems relating to modules being independent
> instances?
I've had problems with two inst
Hello guys,
I want to sum up all strange things about the behaviour of `__name__`, a
special key present in every section of a parser instance.
Hopefully it will be removed at once or in the worst case oficially deprecated
and removed in 3.4.
1. There is a special `__name__` key in every sectio
On 30 July 2010 18:32, Michael Foord wrote:
> On 30/07/2010 17:59, Oleg Broytman wrote:
>>
>> On Fri, Jul 30, 2010 at 07:26:26AM +0100, Daniel Waterworth wrote:
>>
>>>
>>> @Oleg: ...
>>> This is purely CPython bug-fixing/the discussion of
>>> implementation choices.
>>>
>>
>> I am not sure it's
On Fri, Jul 30, 2010 at 5:54 PM, Éric Araujo wrote:
>> It has an API, but the plugins are not interface based (so interface
>> requirements don't need to be part of the plugin system).
>
> Oh, I see. With duck-typing and ABCs, I don’t make a difference between
> protocols and interfaces in my head
On 30/07/2010 17:59, Oleg Broytman wrote:
On Fri, Jul 30, 2010 at 07:26:26AM +0100, Daniel Waterworth wrote:
@Oleg: ...
This is purely CPython bug-fixing/the discussion of
implementation choices.
I am not sure it's a bug.
It isn't a bug but it's a very common *cause* of bugs, ev
On Fri, Jul 30, 2010 at 07:26:26AM +0100, Daniel Waterworth wrote:
> @Oleg: ...
> This is purely CPython bug-fixing/the discussion of
> implementation choices.
I am not sure it's a bug. By manipulating sys.path (or symlinks in the
FS) one can import the same file as different modules as many ti
On Jul 30, 2010, at 6:23 AM, 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:
>
> http://www.voidspace.org.uk/python/weblog/ar
ACTIVITY SUMMARY (2010-07-23 - 2010-07-30)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue
number. Do NOT respond to this message.
2804 open (+45) / 18443 closed (+27) / 21247 total (+72)
Open issues with patches: 1151
Ave
On 29 July 2010 07:32, Daniel Waterworth wrote:
> Hi,
>
> I'm not sure if this is a bug or not, I certainly didn't expect it. If
> you create a file called test.py with the following contents,
>
> class Test:
> pass
>
> def test_1():
> import test
> print Test == test.Test
>
> if __name__
> It has an API, but the plugins are not interface based (so interface
> requirements don't need to be part of the plugin system).
Oh, I see. With duck-typing and ABCs, I don’t make a difference between
protocols and interfaces in my head :) Also, the I in API does mean
interface, but not imply b
On 30/07/2010 16:28, Éric Araujo wrote:
Le 30/07/2010 17:04, Michael Foord a écrit :
There is no type checking or interface requirements in my plugin
proposal for unittest. It is essentially an event based system.
Event-based sounds good. unittest2 does have an interface IMO:
configur
Le 30/07/2010 17:04, Michael Foord a écrit :
> There is no type checking or interface requirements in my plugin
> proposal for unittest. It is essentially an event based system.
Event-based sounds good. unittest2 does have an interface IMO:
configuration loading, plugin registration/activation, s
On 30/07/2010 15:41, Marty Alchin wrote:
This is my first post to python-dev, so for those who might not know
me, I'm the author of Pro Django and more recently, Pro Python.
I haven't looked at the plugin landscape in a while, but I was very
disappointed the last time I looked at how complex typ
On 30/07/2010 15:37, Tarek Ziadé wrote:
On Fri, Jul 30, 2010 at 4:04 PM, Barry Warsaw wrote:
..
* Registration - How do third party plugins declare themselves to exist, and
be enabled? Part of this seems to me to include interface declarations
too. Is installation of the plugin enough
On Fri, Jul 30, 2010 at 4:34 PM, Michael Foord
wrote:
...
> Again I think the *needs* of unittest and distutils are different, so I
> wonder if a single system can usefully suit both our needs (let alone
> universally support other systems). Definitely an area worth exploring
> though.
Yes, even
This is my first post to python-dev, so for those who might not know
me, I'm the author of Pro Django and more recently, Pro Python.
I haven't looked at the plugin landscape in a while, but I was very
disappointed the last time I looked at how complex typical systems
were in this regard. There see
On Fri, Jul 30, 2010 at 4:04 PM, Barry Warsaw wrote:
> You guys should definitely write up a plugin PEP!
I am all for it, I am pretty sure we can come up with a generic tool
that can be useful for many packages in the stdlib
Starting this...
--
Tarek Ziadé | http://ziade.org
On Fri, Jul 30, 2010 at 4:04 PM, Barry Warsaw wrote:
..
> * Registration - How do third party plugins declare themselves to exist, and
> be enabled? Part of this seems to me to include interface declarations
> too. Is installation of the plugin enough to register it? How do end users
> enabl
On 30/07/2010 15:04, Barry Warsaw wrote:
On Jul 30, 2010, at 11:38 AM, Michael Foord wrote:
I'm going to read your blog entry on the topic to evaluate it properly
though:
https://tarekziade.wordpress.com/2009/05/01/basic-plugin-system-using-abcs-
and-the-extensions-package/
Very int
On Jul 30, 2010, at 11:38 AM, Michael Foord wrote:
>I'm going to read your blog entry on the topic to evaluate it properly
>though:
>
>https://tarekziade.wordpress.com/2009/05/01/basic-plugin-system-using-abcs-
>and-the-extensions-package/
Very interesting. For Mailman 3, I have YAPS (yet anothe
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:
http://www.voidspace.org.uk/python/weblog/arch_d7_2010_07_24.shtml#e1186
Michael
On 29 July 2010 23:55, Mi
Thank you for your response.
Regards,
Durga.
On Fri, Jul 30, 2010 at 6:05 PM, Oleg Broytman wrote:
> Hello.
>
> We are sorry but we cannot help you. This mailing list is to work on
> developing Python (adding new features to Python itself and fixing bugs);
> if you're having problems learning
Hello.
We are sorry but we cannot help you. This mailing list is to work on
developing Python (adding new features to Python itself and fixing bugs);
if you're having problems learning, understanding or using Python, please
find another forum. Probably python-list/comp.lang.python mailing list/
Hi All,
I am new to python based application developement. I am using Windows XP.
1. Can I create desktop application (just hello world program) with Python
language like exe in VC++?
2. If First statement is Yes, Can I include this application with my
existing setup(assume 10 MB) for win
On 30/07/2010 11:09, Tarek Ziadé wrote:
On Fri, Jul 30, 2010 at 12:55 AM, Michael Foord
wrote:
...
The Plugin Class
A sometimes-more-convenient way of creating plugins is to subclass the
``unittest2.events.Plugin`` class. By default subclassing ``Plugin`` will
auto-instan
On Fri, Jul 30, 2010 at 12:55 AM, Michael Foord
wrote:
...
>
> The Plugin Class
>
>
> A sometimes-more-convenient way of creating plugins is to subclass the
> ``unittest2.events.Plugin`` class. By default subclassing ``Plugin`` will
> auto-instantiate the plugin and store the inst
52 matches
Mail list logo
