On Thu, Apr 9, 2009 at 2:11 PM, Nick Coghlan wrote:
> One of my hopes for PEP 362 was that I would be able to just add
> __signature__ to the list of copied attributes, but that PEP is
> currently short a champion to work through the process of resolving the
> open issues and creating an up to dat
On Wed, Apr 8, 2009 at 7:51 PM, Guido van Rossum wrote:
>
> There was a remark (though perhaps meant humorously) in Michele's page
> about decorators that worried me too: "For instance, typical
> implementations of decorators involve nested functions, and we all
> know that flat is better than nes
On Wed, Apr 8, 2009 at 8:10 AM, Jack diederich wrote:
> Plus he's a softie for decorators, as am I.
I must admit that while I still like decorators, I do like them as
much as in the past.
I also see an overuse of decorators in various libraries for things that could
be done more clearly without t
On Tue, Apr 7, 2009 at 11:04 PM, Terry Reedy wrote:
>
> This probably should have gone to the python-ideas list. In any case, I
> think it needs to start with a clear offer from Michele (directly or relayed
> by you) to contribute it to the PSF with the usual conditions.
I have no problem to con
+ on the syntax, but please keep the hidden logic simple and
absolutely do NOT add confusion
between yield and return. Use yield Return(value) or raise SomeException(value),
as you like. The important thing for me is to have a trampoline in the
standard library, not
the synta
have always felt the lack of a binary operator expressing
non-commutative multiplication.
It could be used for matrices, but also for functions composition and
other more abstract things. I think a single new operator is all is
needed.
Michele Simionato
I like Martin's proposals (use a function, remove -O) very much.
Actually I wanted
to propose the same months ago. Here is my take at the assert function, which
I would like to be able to raise even exceptions different from AssertionError:
def assert_(cond, exc, *args):
"""Raise an exception
On Thu, Sep 4, 2008 at 1:41 AM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> The release
> candidate seems to be the wrong time to
> yank this out (in part because of the surprise
> factor) and in part because I think the change
> silently affects shelve performance so that the
> impact may be si
On Sat, Aug 30, 2008 at 6:16 AM, Michele Simionato
> I wrote a trait library which I plan to release soon or later.
Ok, just for the people here that cannot wait I have prepared a pre-alpha
snapshot and uploaded it to my site:
http://www.phyast.pitt.edu/~micheles/python/strait.html
At s
happens when
you release a library: you will never now what people will
end up using it for ;)
Michele Simionato
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org
On Fri, Aug 29, 2008 at 6:15 PM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> The mixin methods in the ABC machinery would be a lot less useful
> without multiple inheritance (and the collections ABCs would be a whole
> lot harder to define and to write).
>
> So if you're looking for use cases for mul
On Fri, Aug 29, 2008 at 6:22 AM, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> You're right, let's abolish inheritance, too, because then you might have to
> read more than one class to see what's happening.
You are joking, but I actually took this idea quite seriously. Once
(four years ago or so) I
ing multiple inheritance and cooperation, and suggest
alternatives.
Michele Simionato
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
from Python, with single inheritance only,
and not lose much expressivity. I am not advocating any change to
current Python.
My point was in language design: I want to know how much I can remove
from a language
and still have something useful, in the
Alex Martelli wrote:
> What's DebugFrameworkMeta2? I assume it's some kind of mix but I
> don't see it defined anywhere so I'm having to guess.
Sorry Alex, here is definition which got lost in cut&paste:
DebugFrameworkMeta2 = include_mixin(DebugMeta2, FrameworkMeta2)
> I'd like to understand wh
On Wed, Aug 27, 2008 at 4:30 PM, Alex Martelli <[EMAIL PROTECTED]> wrote:
> Maybe you could help me understand this by giving a fully executable
> Python snippet using __bases__[0] instead of the hypothetical
> __base__?
Sorry Alex, I have the fully functional snippet but evidently I have
sent som
On Tue, Aug 26, 2008 at 11:10 PM, Steve Holden <[EMAIL PROTECTED]> wrote:
> If you aren't aware of it you should take a look at Enthought's traits
> package. It's part of the Enthought Tool Suite (ETS).
I know of the existence of that framework, however it is quite
large and I don't see the relati
On Wed, Aug 27, 2008 at 5:15 AM, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> ISTR pointing out on more than one occasion that a major use case for
> co-operative super() is in the implementation of metaclasses. The __init__
> and __new__ signatures are fixed, multiple inheritance is possible, and
On Tue, Aug 26, 2008 at 6:13 PM, Michele Simionato
<[EMAIL PROTECTED]> wrote:
> I not completely against multiple inheritance. I am against multiple
> inheritance
> as it is now. A restricted form of multiple inheritance in which mixins
> classes
> are guaranteed to be ort
On Wed, Aug 27, 2008 at 3:30 AM, Alex Martelli <[EMAIL PROTECTED]> wrote:
> On Tue, Aug 26, 2008 at 6:16 PM, Michele Simionato
> <[EMAIL PROTECTED]> wrote:
> ...
>> It is just a matter of how rare the use cases really are. Cooperative
>> methods has been introduc
On Tue, Aug 26, 2008 at 8:56 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> I would state this differently: "The use cases for cooperative multiple
> inheritence don't arise often in practice; so, if we dropped support
> for those cases, you probably wouldn't notice until you encountered
> one
I do not like) and you will also see
that I like DictMixin
instead.
I will publish the papers in the blog soon or later, but you can find
the Italian version here:
http://stacktrace.it/articoli/2008/06/i-pericoli-della-programmazione-con-i-mixin1/
http://stacktrace.it/articoli/2008/07/i-pericoli-de
Michele Simionato gmail.com> writes:
> Finally I did some timing of code like this::
>
> from itertools import imap
> Point = namedtuple('Point x y'.split())
>
> lst = [(i, i*i) for i in range(500)]
>
> def with_imap():
> for _ in imap(Point, l
lists;
2. put a check in the metaclass such as
``assert '__init__' not in bodydict`` to make clear to the users
that they cannot override the __init__ method, that's the metaclass job.
Great hack!
Michele Simionato
_
it seems a bit odd. Yet, the decision isn't central to
> the proposal and is still an open question.
``Contract = namedtuple('Contract stock strike volatility expiration rate
iscall'.split())`` is not that bad either, but I agree that this is a
second order issue.
Michele
e('Point','x','y')
In [3]: Point(1,2)
Out[3]: Point(x=1, y=2)
In [4]: Point.__repr__ = tuple.__repr__
In [5]: Point(1,2)
Out[5]: (1, 2)
It feels clearer to me.
Michele Simionato
___
Python-Dev mailing list
Pyth
Raymond Hettinger verizon.net> writes:
> * Add a pure python named_tuple class to the collections module. I've been
> using the class for about a year and found that it greatly improves the
> usability of tuples as records.
> http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/500261
The
lem. We had to face it at work, and
at the end we decided to use zipstream
(http://www.doxdesk.com/software/py/zipstream.html) instead of zipfile,
but of course having the functionality in the standard library would be
much better.
Michele Simionato
ething like
@expose
def page(self):
return 'Hello World!'
or
@expose
def page(self):
yield 'Hello '
yield 'World!'
indifferently. I seem to remember CherryPy has something like that.
Michele Simionato
__
Nolo contendere.
I am convinced and I am taking back my feature request.
Michele Simionato
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/o
in an improper sense are "instances" of a "generator function".
I.e.
def g(): yield 1 # this is a generator
go = g() # this is a generator object
I want isgenerator(g) == True, but isgenerator(go) == False.
So, what should be the class of g ? Maybe we can keep FunctionType
a
Georg Brandl gmx.net> writes:
> I'd say, go ahead and write a patch including docs, and I think there's no
> problem with accepting it (as long as it comes before beta1).
I was having a look at http://docs.python.org/dev/lib/inspect-types.html
and it would seem that adding isgenerator would impl
t.isfunction gives True on a generator, such
as
def g(): yield None
This could confuse people, however I am inclined to leave things as they are.
Any thoughts?
Michele Simionato
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python
. The one obvious way to me is to have an
inspect.isgenerator, analogous to inspect.isfunction, inspect.ismethod, etc.
The typical use case is in writing a documentation/debugging tool. Now I
was writing a decorator that needed to discriminate in the case it was
decorating a regular function
Is there still time for new feature requests in Python 2.5?
I am missing a isgenerator function in the inspect module. Right now
I am using
def isgenerator(func):
return func.func_code.co_flags == 99
but it is rather ugly (horrible indeed).
Michele Simionato
Recently I downloaded Python 2.5a1 and I have started playing with it. In
doing so,
I have been looking at the Demo directory in the distribution, to check if
demos
of the new features have been added there. So, I rediscovered brownian.py,
in Demo/tkinter/guido. I just love this little program, b
uages;
- ...
This is way I see a 'create' statement is frightening powerful addition to the
language.
Michele Simionato
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
ereas I
would freely use a 'create' statement.
Michele Simionato
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
pinion counts on this matters ;)
Anyway I expected people to criticize the proposal as too powerful and
dangerously close to Lisp macros.
Michele Simionato
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/lis
As other explained, the syntax would not work for functions (and it is
not intended to).
A possible use case I had in mind is to define inlined modules to be
used as bunches
of attributes. For instance, I could define a module as
module m():
a = 1
b = 2
where 'module' would be the followi
in d
> del d['__builtins__']
>
> then is the resulting value of d.
>
> Interesting idea...
>
> Paul.
>
would be a string and a dictionary.
As I said, the semantic would be exactly the same as the current
wa
_this')
Notice that the proposal is already implementable by abusing the class
statement:
class :
__metaclass__ =
But abusing metaclasses for this task is ugly. BTW, if the proposal was
implemented, the 'class' would become redundant and could
rty('x')
c = C()
c.x = 1
print c.x
But in general I prefer to write a custom descriptor class, since it
gives me much more control.
Michele Simionato
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/ma
On 5/13/05, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Michele Simionato wrote:
>
> > def divide1(n1, n2):
> > try:
> > result = n1/n2
> > finally:
> > print "cleanup"
> > result = "Infinity\n"
&
d me that a
finally clause could hide my exception.
Michele Simionato
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
_something
let open("myfile") as f:
for line in f: do_something(line)
or even, without need of "as":
let f=file("myfile") :
for line in f: do_something(line)
which I actually like more
Michele Simionato
eve it.
It is enough to add some documentation about "super" caveats
and nonobvious points.
What I really dislike is super called with only one argument since
it has many unpleasant surprises and not real advantages :-(
Michele Simionato
__
I have a non-feature
request about the descriptor aspect of super: I would like super's
__get__ method
and the possibily to call super with just one argument to be removed
in Python 3000.
They are pretty much useless (yes I know of "autosuper") and error prone.
Michele
On 5/10/05, Michele Simionato <[EMAIL PROTECTED]> wrote:
>
> Well, actually I am even more ambitious than that: not only I would like
> to be able to copy functions, but I also would like to be able to subclass
> FunctionType with an user-defined __copy__ method.
BTW, it seem
not only I would like
to be able to copy functions, but I also would like to be able to subclass
FunctionType with an user-defined __copy__ method.
Don't worry, I will submit the feature request ;)
Michele Simionato
P.S. I have added yet another example to the documentation of
t!
I have updated my module to version 0.2, with an improved discussion
of decorators in multithreaded programming ("locked", "threaded",
"deferred"): http://www.phyast.pitt.edu/~micheles/python/decorator.zip
Michele Simionato
line += yield_()
print line,
if line == 'quit\n':
print "are you sure?"
if yield_() == 'y':
break
process_commands.switch() # start the greenlet
send("h&quo
gs, **kw)
>>> @chatty
... def f(): pass
>>> f()
Calling 'f'
"""
def __init__(self, caller):
self.caller = caller
def __call__(self, func):
return _decorate(func, self.caller)
Michele Simionato
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Honestly, I don't care, since "eval" happens only once at decoration time.
There is no "eval" overhead at calling time, so I do not expect to have
problems. I am waiting for volunteers to perform profiling and
performance analysis ;)
Michele Simionato
_
On 5/5/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>
> Yes, there has been quite a bit of interest including several ASPN
> recipes and a wiki:
>
>http://www.python.org/moin/PythonDecoratorLibrary
Thanks, I didn't know about that page. BTW, I notice that all the decorators
in that page
esting in this
moment, since decorators may address many of the use cases
of PEP 340 (not all of them).
I need to write down some documentation, but it could be done by tomorrow.
What do people think?
Michele Simionato
___
Python-Dev mailing lis
56 matches
Mail list logo
