matt westerburg wrote:
> Hi my name is Matt Westerburg, I am a student and have only recently
> gotten into Python. But have fallen in love with the language thus
> far. Fantastic language and thank you very much for making it what it
> is today. I am looking into getting into working on Python.
Bruce Christensen wrote:
> Is something like the following close?
Close, yes.
> if type(result) == tuple:
> ... (do appropriate things here)
> elif isinstance(result, basestring):
> name = result
> module = ""
> try:
> module = obj.__module__
>
On 7/17/06, matt westerburg <[EMAIL PROTECTED]> wrote:
Hi my name is Matt Westerburg, I am a student and have only recently gotten into Python. But have fallen in love with the language thus far. Fantastic language and thank you very much for making it what it is today. I am looking into getting
Hi my name is Matt Westerburg, I am a student and have only recently gotten into Python. But have fallen in love with the language thus far. Fantastic language and thank you very much for making it what it is today. I am looking into getting into working on Python. Still need sometime working w
I'm still plugging away on IronPython's cPickle, and I've stumbled
across another ambiguity in the pickle docs. From
http://docs.python.org/lib/node69.html:
"If a string is returned, it names a global variable whose contents are
pickled as normal. The string returned by __reduce__ should be the
ob
Boris Borcic <[EMAIL PROTECTED]> wrote:
> Josiah Carlson wrote:
> > Invariably user X and Y would have different sets of changes that they
> > want to use. Presumably, if the features were nontrivial, then they
> > would no longer be able to exchange code because it would have been
> > directed a
Boris Borcic wrote:
>> Boris Borcic <[EMAIL PROTECTED]> wrote:
>>
>> [snip..]
> I am just saying :
>
> (1) be aware that "reversible source to source transforms" means that
> language
> differences can *EFFECTIVELY* be made invisible - turned to purely private
> choices (in the sense of "be
Josiah Carlson wrote:
> Boris Borcic <[EMAIL PROTECTED]> wrote:
>> Guido van Rossum wrote:
>>> You must be misunderstanding.
>> I don't think so. You appeared to say that the language changes too much
>> because
>> everyone wants different changes - that accumulate. I suggested a mechanism
>> al
Hi,
This is reported on sourceforge:
http://sourceforge.net/tracker/index.php?func=detail&aid=1524081&group_id=5470&atid=105470
I am willing to try and patch the problem, but I'd like to discuss my ideas
first.
The basic problem is that, in some locale, "INFO".lower() != "info". So,
initializin
On Jul 17, 2006, at 11:25 AM, Armin Rigo wrote:
> Hi Bob,
>
> On Thu, Jul 13, 2006 at 12:58:08AM -0700, Bob Ippolito wrote:
>>> @main
>>> def whatever():
>>> ...
>>
>> It would probably need to be called something else, because main is
>> often the name of the main function...
>
> Ah, but the
Hi Bob,
On Thu, Jul 13, 2006 at 12:58:08AM -0700, Bob Ippolito wrote:
> > @main
> > def whatever():
> > ...
>
> It would probably need to be called something else, because main is
> often the name of the main function...
Ah, but there is theoretically no name clash here :-)
@main
Hi Jeroen,
On Thu, Jul 13, 2006 at 02:02:22PM +0200, Jeroen Ruigrok van der Werven wrote:
> He doesn't specifically need the builtin types to be extendable. It's
> just nice to be able to define a single class in multiple modules.
There are various simple ways to do this; the one I'm using from t
On 7/16/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> For about the third time in my life, I thought I might
> have found a use for cooperative super calls, but I've
> run into another problem with the concept.
>
> Consider:
>
> class A(object):
>def m(self):
> print "A.m"
>
> class B(ob
Boris Borcic <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > You must be misunderstanding.
>
> I don't think so. You appeared to say that the language changes too much
> because
> everyone wants different changes - that accumulate. I suggested a mechanism
> allowing people to see only
On Mon, 17 Jul 2006 10:29:22 -0300, Johan Dahlin <[EMAIL PROTECTED]> wrote:
>I consider __getattribute__ a hack, being able to override __dict__ is less
>hackish, IMHO.
Why do you feel one is more "hackish" than the other? In my experience the
opposite is true: certain C APIs expect __dict__ to
On Monday 17 July 2006 20:27, Andrew MacIntyre wrote:
> On the face of it, it seems to me that branching a new major
> release at the 1st beta would be one way of managing this. The
> trunk is not frozen for an extended period, and any "features" and
> bug fixes could probably be backported from t
Phillip J. Eby wrote:
> Just as a point of reference, the Importing package does something very
> similar, to support "weak" and "lazy" imports:
>
> http://cheeseshop.python.org/pypi/Importing
Interesting, I was not aware of that, thanks for the pointer.
Another reason for including this feature
James Y Knight wrote:
>
> On Jul 15, 2006, at 2:38 PM, Johan Dahlin wrote:
>> What I want to ask, is it possible to have a sanctioned way to implement
>> a dynamic module/namespace in python?
>>
>> For instance, it could be implemented to allow you to replace the
>> __dict__ attribute in a module
Anthony Baxter wrote:
> On Friday 14 July 2006 22:45, Jeremy Hylton wrote:
>> Maybe the basic question is right, but the emphasis needs to be
>> changed. If we had a rule that said the final release was 90 days
>> after the last submission that wasn't to fix a regression, we'd ask
>> "Is this feat
Andrew Bennetts wrote:
> On Sat, Jul 15, 2006 at 03:38:04PM -0300, Johan Dahlin wrote:
>> In an effort to reduce the memory usage used by GTK+ applications
>> written in python I've recently added a feature that allows attributes
>> to be lazy loaded in a module namespace. The gtk python module c
Barry Warsaw wrote:
> Just as 2.5b2 was being release, I updated SF patch #1520294:
>
> https://sourceforge.net/tracker/index.php?
> func=detail&aid=1520294&group_id=5470&atid=305470
>
> This fixes the pydoc, inspect, and types modules for built-in types
> like getset and member descriptors. I'm
Guido van Rossum wrote:
> You must be misunderstanding.
I don't think so. You appeared to say that the language changes too much
because
everyone wants different changes - that accumulate. I suggested a mechanism
allowing people to see only the changes they want - or none at all - might be
dev
On Sun, Jul 16, 2006 at 11:52:48PM -0700, Josiah Carlson wrote:
> Andrew Bennetts <[EMAIL PROTECTED]> wrote:
[...]
> >
> > Have you seen the "demandload" hack that Mercurial uses? You can find it
> > here:
> > http://selenic.com/repo/hg?f=cb4715847a81;file=mercurial/demandload.py
> >
> > Yo
On Friday 14 July 2006 22:45, Jeremy Hylton wrote:
> Maybe the basic question is right, but the emphasis needs to be
> changed. If we had a rule that said the final release was 90 days
> after the last submission that wasn't to fix a regression, we'd ask
> "Is this feature important enough to warr
Yingbo Qiu wrote:
> Will anyone have interest in the patch?
This patch comes to late for Python 2.5. It might be considered for 2.6,
if anybody has time to review it.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.o
25 matches
Mail list logo
