Felipe Almeida Lessa wrote:
Em Sex, 2006-04-14 às 09:31 -0600, Steven Bethard escreveu:
[1] Here's the code I used to test it.
def make(callable, name, args, block_string):
... try:
... make_dict = callable.__make_dict__
... except AttributeError:
... make_dict =
Steven Bethard wrote:
Ok, I finally have a PEP number. Here's the most updated version of the
make statement PEP. I'll be posting it shortly to python-dev.
Thanks again for the previous discussion and suggestions!
I find it very interesting.
My only complaint is that it is limited to
Steven Bethard wrote:
...
Yes, you have to explain descriptors, but at the point that you start
trying to do funny things with staticmethods and classmethods, I think
you need to start learning about them anyway.)
That's all good points, but IMHO, descriptors are a much more advanced
Hi everyone,
I was wondering if it would make sense to make staticmethod objects
callable, so that the following code would work:
class A:
@staticmethod
def foo(): pass
bar = foo()
I understand staticmethod objects don't need to implement __call__ for
their other use cases, but
Felipe Almeida Lessa wrote:
Em Ter, 2006-02-28 às 15:17 -0500, Nicolas Fleury escreveu:
class A:
@staticmethod
def foo(): pass
bar = foo()
# Why not:
def foo(): pass
class A:
bar = foo()
foo = staticmethod(foo)
Well, you could even do:
class
Steven Bethard wrote:
Nicolas Fleury wrote:
I was wondering if it would make sense to make staticmethod objects
callable, so that the following code would work:
class A:
@staticmethod
def foo(): pass
bar = foo()
Do you have a real-world use case? I pretty much never use
Jakob Simon-Gaarde wrote:
Follow-up on a thread from 1999 (see below)
Well now it is 2005 and the operating system I'm using is Windows
Server 2003, and I can still see that the same problem persists with:
win32pipe.popen2()
win32pipe.popen3()
win32pipe.popen4()
while
Martin v. Löwis wrote:
Nicolas Fleury wrote:
Well, I'm using the alternatives.
Perhaps not to the full power.
Not perhaps, surely;) Who does anyway;)
So you don't want to write the makeArrayType function, right?
How about this:
# declaration
class Array(object):
__typeargs__
Kay Schluehr wrote:
def makeClass(cls_name, **kw):
return type(cls_name,(), kw)
MyObject = makeClass(MyObject,a=8)
MyObject
As said to Bengt, a place is needed to write the class definition.
There's no need for metaclass in that case:
def makeType(a, b, c=someDefault):
arguments =
Kay Schluehr wrote:
I have to admit that i don't actually understand what you want? The
problems you try to solve seem trivial to me but it's probably my fault
and i'm misreading something. You might be correct that your PEP may be
interesting only if optional static typing will be introduced
Bengt Richter wrote:
On Sun, 07 Aug 2005 21:41:33 -0400, Nicolas Fleury [EMAIL PROTECTED] wrote:
I mean should angle brackets like in C++, or another operator, be
used instead?
I am getting the feeling that your PEP is about a means to do something
C++-like
in python, not necessarily
Bengt Richter wrote:
On Mon, 08 Aug 2005 16:18:50 -0400, Nicolas Fleury [EMAIL PROTECTED] wrote:
I wrote the PEP to see if was the only one that would benefit from
generic types *before* having optional static typing in the language.
It seems I'm the only one;)
According to blog entry 86641
Hi everyone, I would to know what do you think of this PEP. Any comment
welcomed (even about English mistakes).
PEP:XXX
Title: Specialization Syntax
Version:$Revision: 1.10 $
Last-Modified: $Date: 2003/09/22 04:51:49 $
Author: Nicolas Fleury nidoizo at gmail.com
Status
Martin v. Löwis wrote:
-1. I don't see the point of this PEP. Apparently, you want to define
parametrized types - but for what purpose? I.e. what are the specific
use cases for the proposed syntax, and why do you need to change the
language to support these use cases? I very much doubt that
Bengt Richter wrote:
__specialize__ Special Member Function.
By Member Function do you mean anything different from method?
No, I should have written method. C++ habit.
The first element of this proposal is the addition of the
__specialize__ special member function. The
Bengt Richter wrote:
I don't understand why you wouldn't give the function arg a different name
in the first place instead of via a temporary intermediary binding, e.g.,
def makeType(someArgument_alias):
class MyObject:
someArgument = someArgument_alias
return
Brett Hoerner wrote:
This is a pretty basic, mostly un-python-related question, although I'm
asking because of Python.
Is there a different shell I can use (other than cmd.com) to run Python
in, where I can full-screen the window (if I pleased), etc? As it is,
things that would run far off
Steven D'Aprano wrote:
One of the things I liked in Pascal was the with keyword. You could
write something like this:
with colour do begin
red := 0; blue := 255; green := 0;
end;
instead of:
colour.red := 0; colour.blue := 255; colour.green := 0;
Okay, so maybe it is more of a
Hi,
I've made a small utility to re-raise an exception with the same stack
as before with additional information in it. Since I want to keep the
same exception type and that some types have very specific constructors
(which take, for example, more than one parameter), the only safe way I
have
Scott David Daniels wrote:
How about dropping reraise and changing:
reraise(...)
to:
addinfo(...)
raise
It doesn't work, or at least it doesn't do what I want. I want to keep
the same exception stack to be able to identify the original error. I
would like to
Scott David Daniels wrote:
Have you tried it? Looked to do what you described to me when I run a
sample. Note that is an unadorned raise with no args. The idea is to
simply modify the exception object and then use raise to carry the
whole original exception along as if not intercepted.
Ron Adam wrote:
It occurred to me (a few weeks ago while trying to find the best way to
form a if-elif-else block, that on a very general level, an 'also'
statement might be useful. So I was wondering what others would think
of it.
But the feature is already there:
for x in iterable:
Steven Bethard wrote:
Can you do the same thing for your proposal? As I understand it you
want some sort of implicitly-defined BLOCK that starts the line after
the with statement and runs to the end of the current block...
Yes. I totally agree with the syntax in the PEP, it provides a
Delaney, Timothy C (Timothy) wrote:
Nicolas Fleury wrote:
def getFirstLine(filename):
with opening(filename) as file
return file.readline()
Your tastes definitely disagree with the majority of Python programmers
then, including Guido. Scoping is defined in Python by indentation
Andrew Dalke wrote:
The implementation would need to track all the with/as forms
in a block so they can be __exit__()ed as appropriate. In this
case ghi.__exit() is called after jkl.__exit__() and
before defg.__exit__
The PEP gives an easy-to-understand mapping from the proposed
change to
Ilpo Nyyssönen wrote:
Nicolas Fleury [EMAIL PROTECTED] writes:
What about making the ':' optional (and end implicitly at end of current
block) to avoid over-indentation?
def foo():
with locking(someMutex)
with opening(readFilename) as input
with opening(writeFilename) as output
Andrew Dalke wrote:
Consider the following
server = open_server_connection()
with abc(server)
with server.lock()
do_something(server)
server.close()
it would be translated to
server = open_server_connection()
with abc(server):
with server.lock()
do_something(server)
Guido van Rossum wrote:
After many rounds of discussion on python-dev, I'm inviting public
comments for PEP 343. Rather than posting the entire PEP text here,
I'm inviting everyone to read it on line
(http://www.python.org/peps/pep-0343.html) and then post comments on a
Wiki page I've created
Andrew Dalke wrote:
def foo():
with locking(someMutex)
with opening(readFilename) as input
with opening(writeFilename) as output
...
Nothing in Python ends at the end of the current block.
They only end with the scope exits. The order of deletion
Charles Krug wrote:
I've a function that needs to maintain an ordered sequence between
calls.
In C or C++, I'd declare the pointer (or collection object) static at
the function scope.
What's the Pythonic way to do this?
Is there a better solution than putting the sequence at module scope?
Thanks.
Shane Hathaway wrote:
I like this PEP a lot, but your concern is valid. Maybe Brian could
modify the PEP slightly to disambiguate. How about using an ellipsis in
the argument list to signify suite-based keywords? Examples:
f(...):
x = 1
class C(object):
x = property(...):
doc = I'm
[EMAIL PROTECTED] wrote:
There is no event handle used in Event object (for NT at least). Do not
know about Linux...
And there's no handle at all? It's not important if it's not an event
handle as long as it is an handle usable with WaitForMultipleObjects.
Also, I don't understand how it will
[EMAIL PROTECTED] wrote:
//And there's no handle at all?
There is one (check thread_nt.h) you have to propagate HANDLE to
Pythom level. That's why, you have to change the interpreter. Do not
forget, that thread is a build-in module.
Sounds fine with me. A fileno (or whatever) function can be
Hi,
Is there any way to get the file descriptor on Unix or handle on Windows
associated internally with a threading.Event object? So that it can be
used in a call to select or WaitForMultipleObjects.
Thx and regards,
Nicolas
--
http://mail.python.org/mailman/listinfo/python-list
Hi,
I want to use the subprocess module (or any standard Python module) to
run a process:
- which stdout and stderr can each be redirected to any file-like object
(no fileno function).
- can be cancelled with a threading.Event.
My problem is that the subprocess.Popen constructor doesn't seem
Hi,
I'm trying to support two Python versions at the same time and I'm
trying to find effective mechanisms to support modules compiled in C++
transparently.
All my code in under a single package. Is it possible to override the
import mechanism only for modules under that package and
Nicolas Fleury wrote:
import cppmymodule
would be equivalent to:
if sys.version == 2.4:
import cppmymodule24 as cppmymodule
elif sys.version == 2.3:
import cppmymodule23 as cppmymodule
for all modules under the package and all modules with names beginning
with cpp (or another way
Mirko Zeibig wrote:
This is not an option for e.g. IDEs as some functions might actually do
something when called ;-) and I like `callable` for introspection.
Other ways would be to check for the `__call__` attribute or use several
methods of the `inspect`-Module, both of which are not better
it's me wrote:
Okay, Nick, I didn't know you can pass a Class rather then an instance. I
have to chew on what your example does.
But no, I want to pass an instance of a Class. But how do I know that the
calling routine *did* pass me a class - pardon me: an instance of a Class?
You have the
David M. Cooke wrote:
Ideally, I think the better way is if getattr, when raising
AttributeError, somehow reused the old traceback (which would point
out the original problem). I don't know how to do that, though.
Maybe a solution could be to put the attribute name in the
AttributeError exception
an_instance=Abc()
But what good is that? Of course I know Abc is a class, why would I want to
inspect it so that it would tell me what I already know?
Well, for no reason in that case. For the same reason you would not
call isinstance(an_instance, Abc) if you already know an_instance is an
It's me wrote:
I guess another example would be an assert on the type of argument:
def foo(someClass):
assert inspect.isclass(someClass)
# rest of code
But that would always fail! (I just tried it).
Are you sure you haven't pass an instance instead of a class? Remember,
classes are also
42 matches
Mail list logo
