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:
>> ...
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 t
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
Py
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 =
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()
&g
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 w
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 win32pi
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:
&g
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
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 somet
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 introd
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):
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
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 _
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
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
Status: Draft
Type
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 fa
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 m
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.
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 lik
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
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 :
BLO
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. S
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
n
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(serv
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)
>>
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
> cha
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
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 cre
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.
Y
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:
//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 add
[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 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 to
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 cp
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 sub-packa
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 th
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 buil
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
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
ins
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
42 matches
Mail list logo
