Python-list Digest, Vol 82, Issue 48
francisco dorset
certifiedlover at hotmail.com
Tue Jul 6 06:03:26 EDT 2010
i need resources or books on how to embedding python into c/c++...and also extending it
am allergic to cheating, i hate failures, but am in love with achievements
<º))))><.·´¯`·.F®an©ï§CØ`·.¸¸¸.·´¯`·.¸><((((º>
From: python-list-request at python.org
Subject: Python-list Digest, Vol 82, Issue 48
To: python-list at python.org
Date: Tue, 6 Jul 2010 08:25:02 +0200
Send Python-list mailing list submissions to
python-list at python.org
To subscribe or unsubscribe via the World Wide Web, visit
http://mail.python.org/mailman/listinfo/python-list
or, via email, send a message with subject or body 'help' to
python-list-request at python.org
You can reach the person managing the list at
python-list-owner at python.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Python-list digest..."
--Forwarded Message Attachment--
From: martin at v.loewis.de
To: python-list at python.org
Date: Tue, 6 Jul 2010 05:28:00 +0200
Subject: Re: Python 2.7 released
> Benjamin (or anyone else), do you know where I can get the Compiled
> Windows Help file -- python27.chm -- for this release?
I have now put that file separately on the release page.
Regards,
Martin
--Forwarded Message Attachment--
From: kedra.marbun at gmail.com
To: python-list at python.org
Date: Mon, 5 Jul 2010 21:10:51 -0700
Subject: Re: delegation pattern via descriptor
On Jul 5, 3:42 pm, Bruno Desthuilliers <bruno.
42.desthuilli... at websiteburo.invalid> wrote:
> kedra marbun a écrit :
>
>
>
> > i'm confused which part that doesn't make sense?
> > this is my 2nd attempt to py, the 1st was on april this year, it was
> > just a month, i'm afraid i haven't got the fundamentals right yet. so
> > i'm gonna lay out how i got to this conclusion, CMIIW
>
> > **explanation of feeling (0) on my 1st post**
> > to me, descriptor is a particular kind of delegation, it takes the job
> > of coding the delegation by having a contract with programmers that
> > the tree meta operations (get, set, del) on attr are delegated to the
> > obj that is bound to the attr
> > are we agree that descriptor is a kind of delegation?
>
> > the mechanism that makes descriptor works is in __getattribute__,
> > __setattr__, __delattr__ of 'object' & 'type'
>
> > now, if i want a single descriptor obj to be delegated to multiple
> > tasks, i can't do it since __get__ doesn't get info that can be used
> > to determine which task to do
> > i must have diff descriptor obj for each task
>
> > class Helper:
> > def __init__(self, name):
> > self.name = name
> > def __get__(self, ins, cls):
> > if self.name == 'task0': ...
> > elif self.name == 'task1': ...
> > else: ...
>
> Replacing such "big switch" code with polymorphic dispatch is one of the
> goals (and feature) of OO. This should be:
>
> class Task0(object):
> def __get__(self, obj, cls):
> # code here
>
> class Task1(object):
> def __get__(self, obj, cls):
> # code here
>
> class A(object):
> task0 = Task0()
> task1 = Task1()
>
> If you have common code to share between TaskO and Task1 then factor it
> out into a base class.
>
> > if __get__ receives the name, then i could do
>
> > class Helper:
> > def __get__(self, ins, cls, name):
> > ...
>
> > class a:
> > task0 = task1 = Helper()
>
> Yuck.
what's so 'Yuck' about it? ;)
i guess i need a strong stmt: is descriptor a kind of delegation? or
is it not?
* if it is a kind of delegation, then the code that you labeled as
'Yuck' is just a result of applying delegation
what's wrong with delegating multiple tasks to a single obj?
that code is similar to this
class Helper:
def do_this(self, ins): ...
def do_that(self, ins): ...
class a:
delegate = Helper()
def task0(self): self.delegate.do_that(self)
def task1(self): self.delegate.do_this(self)
the diff is that this code manually code the delegation, that's why it
can branches to 2 funcs. while descriptor takes all to __get__,
because it works on more meta lv
* if it's not, then there's nothing to be argued, the name
'descriptor' is perfectly fit: descriptor obj describes attr of class,
with 'describe' translates to: . = del, in py vocabularies. then, to
think a single descriptor obj describing a single attr is acceptable,
it's a common sense
--Forwarded Message Attachment--
From: kedra.marbun at gmail.com
To: python-list at python.org
Date: Mon, 5 Jul 2010 21:12:47 -0700
Subject: Re: delegation pattern via descriptor
On Jul 5, 7:49 am, Gregory Ewing <greg.ew... at canterbury.ac.nz> wrote:
> kedra marbun wrote:
> > now, i'm asking another favor, what about the 2nd point in my 1st post?
>
> Your original post has dropped off my newsscope, so
> you'll have to remind me what the 2nd point was.
>
> --
> Greg
it's like 'name', it's about info that i think should be passed to
descriptor's __{get|set|delete}__. i wonder what are the reasons for
not passing the class on which the descriptor is attached to, what
pattern is encouraged by this?
--Forwarded Message Attachment--
From: kedra.marbun at gmail.com
To: python-list at python.org
Date: Mon, 5 Jul 2010 21:15:33 -0700
Subject: Re: Getting the name of the file that imported current module
On Jul 5, 6:29 am, Steven D'Aprano <st... at REMOVE-THIS-
cybersource.com.au> wrote:
> On Sun, 04 Jul 2010 21:05:56 +0000, Tobiah wrote:
> > foo.py:
>
> > import bar
> > bar.show_importer()
>
> > output:
>
> > 'foo' or 'foo.py' or 'path/to/foo' etc.
>
> > Possible?
>
> I don't think so. Your question isn't even well-defined. Given three
> modules:
>
> # a.py
> import b
> import d
>
> # b.py
> import d
>
> # c.py
> import a
> import d
> import b
> print d.show_importer()
>
> and you run c.py, what do you expect d.show_importer() to return?
>
> And what about "from d import show_importer" -- does that count as
> "importing d"?
>
> Why do you think that a module needs to know what other modules imported
> it? I can't imagine why this would be necessary, what are you intending
> to do with it?
>
> --
> Steven
i guess he just likes to play things around, entertains his
imagination, no need for practical reason for that
--Forwarded Message Attachment--
From: kedra.marbun at gmail.com
To: python-list at python.org
Date: Mon, 5 Jul 2010 21:25:26 -0700
Subject: Re: Getting the name of the file that imported current module
On Jul 5, 4:05 am, Tobiah <t... at rcsreg.com> wrote:
> foo.py:
>
> import bar
> bar.show_importer()
>
> output:
>
> 'foo' or 'foo.py' or 'path/to/foo' etc.
>
> Possible?
>
> Thanks,
>
> Tobiah
if what you mean by 'importer' is the one that really cause py to load
the mod, then why not dynamically set it?
foo.py
------
import bar, sys
if '_importer' not in bar.__dict__: bar._importer =
sys.modules[__name__]
bar.py
------
def show_importer(): return _importer
or
you could borrow space from builtins. i don't know if it breaks any
rule ;)
foo.py
------
def set_importer(mod):
bdict = (__builtins__.__dict__ if __name__ == '__main__' else
__builtins__)
if '_importer' not in bdict:
bdict['_importer'] = {mod : sys.modules[__name__]}
else:
if mod not in bdict:
bdict['_importer'][mod] = sys.modules[__name__]
import bar
set_importer(bar)
--Forwarded Message Attachment--
From: nagle at animats.com
To: python-list at python.org
Date: Mon, 5 Jul 2010 21:45:07 -0700
Subject: Re: Getting pyparsing to backtrack
On 7/5/2010 3:19 PM, John Nagle wrote:
> I'm working on street address parsing again, and I'm trying to deal
> with some of the harder cases.
The approach below works for the cases given. The "Or" operator ("^")
supports backtracking, but "Optional()" apparently does not.
direction = Combine(MatchFirst(map(CaselessKeyword, directionals)) +
Optional(".").suppress())
streetNameOnly = Combine(OneOrMore(Word(alphanums)), adjacent=False,
joinString=" ").setResultsName("streetname")
streetNameParser =
((direction.setResultsName("predirectional") + streetNameOnly)
^ streetNameOnly)
John Nagle
--Forwarded Message Attachment--
From: steve-REMOVE-THIS at cybersource.com.au
To: python-list at python.org
Date: Tue, 6 Jul 2010 05:11:09 +0000
Subject: Re: delegation pattern via descriptor
On Mon, 05 Jul 2010 21:12:47 -0700, kedra marbun wrote:
> On Jul 5, 7:49 am, Gregory Ewing <greg.ew... at canterbury.ac.nz> wrote:
>> kedra marbun wrote:
>> > now, i'm asking another favor, what about the 2nd point in my 1st
>> > post?
>>
>> Your original post has dropped off my newsscope, so you'll have to
>> remind me what the 2nd point was.
>>
>> --
>> Greg
>
> it's like 'name', it's about info that i think should be passed to
> descriptor's __{get|set|delete}__. i wonder what are the reasons for not
> passing the class on which the descriptor is attached to, what pattern
> is encouraged by this?
Perhaps I'm missing the context, but since the descriptor is passed the
instance, you can easily get the class with type(self) or self.__class__.
There's no need to pass the class as a separate argument.
--
Steven
--Forwarded Message Attachment--
From: rami.chowdhury at gmail.com
CC: kedra.marbun at gmail.com
To: python-list at python.org
Date: Mon, 5 Jul 2010 22:40:03 -0700
Subject: Re: delegation pattern via descriptor
On Monday 05 July 2010 21:10:51 kedra marbun wrote:
> On Jul 5, 3:42 pm, Bruno Desthuilliers <bruno.
>
> 42.desthuilli... at websiteburo.invalid> wrote:
> > kedra marbun a écrit :
> > > i'm confused which part that doesn't make sense?
> > > this is my 2nd attempt to py, the 1st was on april this year, it was
> > > just a month, i'm afraid i haven't got the fundamentals right yet. so
> > > i'm gonna lay out how i got to this conclusion, CMIIW
> > >
> > > **explanation of feeling (0) on my 1st post**
> > > to me, descriptor is a particular kind of delegation, it takes the job
> > > of coding the delegation by having a contract with programmers that
> > > the tree meta operations (get, set, del) on attr are delegated to the
> > > obj that is bound to the attr
> > > are we agree that descriptor is a kind of delegation?
> > >
> > > the mechanism that makes descriptor works is in __getattribute__,
> > > __setattr__, __delattr__ of 'object' & 'type'
> > >
> > > now, if i want a single descriptor obj to be delegated to multiple
> > > tasks, i can't do it since __get__ doesn't get info that can be used
> > > to determine which task to do
> > > i must have diff descriptor obj for each task
> > >
> > > class Helper:
> > > def __init__(self, name):
> > > self.name = name
> > > def __get__(self, ins, cls):
> > > if self.name == 'task0': ...
> > > elif self.name == 'task1': ...
> > > else: ...
> >
> > Replacing such "big switch" code with polymorphic dispatch is one of the
> > goals (and feature) of OO. This should be:
> >
> > class Task0(object):
> > def __get__(self, obj, cls):
> > # code here
> >
> > class Task1(object):
> > def __get__(self, obj, cls):
> > # code here
> >
> > class A(object):
> > task0 = Task0()
> > task1 = Task1()
> >
> > If you have common code to share between TaskO and Task1 then factor it
> > out into a base class.
> >
> > > if __get__ receives the name, then i could do
> > >
> > > class Helper:
> > > def __get__(self, ins, cls, name):
> > > ...
> > >
> > > class a:
> > > task0 = task1 = Helper()
> >
> > Yuck.
>
> what's so 'Yuck' about it? ;)
> i guess i need a strong stmt: is descriptor a kind of delegation? or
> is it not?
Thanks for posting the code sample -- it makes your meaning a great deal
clearer. No, descriptors are not delegation as in your sample**, although they
are very flexible and could be used to implement that if you wanted.
> * if it's not, then there's nothing to be argued, the name
> 'descriptor' is perfectly fit: descriptor obj describes attr of class,
> with 'describe' translates to: . = del, in py vocabularies. then, to
> think a single descriptor obj describing a single attr is acceptable,
> it's a common sense
** As I understand it, anyway -- someone please correct me if I'm wrong.
----
Rami Chowdhury
"Never attribute to malice that which can be attributed to stupidity." --
Hanlon's Razor
+1-408-597-7068 / +44-7875-841-046 / +88-01819-245544
--Forwarded Message Attachment--
From: tjreedy at udel.edu
To: python-list at python.org
Date: Tue, 6 Jul 2010 01:37:41 -0400
Subject: Re: The real problem with Python 3 - no business case for conversion (was "I strongly dislike Python 3")
On 7/5/2010 9:00 PM, Philip Semanchuk wrote:
>
> On Jul 5, 2010, at 6:41 PM, Chris Rebert wrote:
>
>> On Mon, Jul 5, 2010 at 3:38 PM, Philip Semanchuk
>>> I ported two pure C extensions from 2 to 3 and was even able to keep a
>>> single C codebase. I'd be willing to contribute my experiences to a
>>> document
>>> somewhere. (Is there a Wiki?)
>>
>> Indeed there is: http://wiki.python.org/moin/
>
> Thanks. I don't want to appear ungrateful, but I was hoping for
> something specific to the 2-to-3 conversion. I guess someone has to
> start somewhere...
There is an existing 2to3 and other pages for Python code conversion. I
do not know of any for CAPI conversion. The need for such has been
acknowledged among the devs but if there is nothing yet, we need someone
with specialized experience and a bit of time to make a first draft. If
you start one, give it an easy to remember name C2to3? 2to3Capi? You
choose. And link to it from the 2to3 page
In his post on this thread, Martin Loewis volunteered to list what he
knows from psycopg2 if someone else will edit.
--
Terry Jan Reedy
--Forwarded Message Attachment--
From: db3l.net at gmail.com
To: python-list at python.org
Date: Tue, 6 Jul 2010 02:06:21 -0400
Subject: Re: Python 2.7 released
Martineau <ggrp2.20.martineau at dfgh.net> writes:
> Some clarification. I meant installed 2.7 on top of 2.6.x. Doing so
> would have interfered with the currently installed version because I
> always install Python in the same directory, one named just "Python",
> to minimize the number of changes I have to make to to other parts of
> the system.
That's fine, you're just making a conscious choice to only support
(yourself) a single version installed at a time.
I tend to need multiple versions around when developing, so I keep a
bunch of versions all installed in separate directories as \Python\x.y
(so I only have a single root directory). With 2.7, my current box
has 6 Python interpreters (2.4-3.1) installed at the moment.
I use Cygwin (wouldn't try to work on a Windows system without it), so
just use bash aliases to execute the right interpreter, but a batch
file could be used with the cmd interpreter, and you could link GUI
shortcuts to that batch file.
Not sure there's a good solution to your help file link, other than
the existing Start menu links installed per Python version. Even with
local links you'd probably want separate links per version anyway
since they're different documents.
Of course, since this started by just considering installing it to get
at a single file (which I know was since solved), it's probably an
acceptable use case for violating your standard policy and picking a
different directory name just in this case, and then blowing it away
later. :-)
> I also believe the Windows installer makes registry
> changes that also involve paths to the currently installed version,
> which again, is something I wanted to avoid until I'm actually ready
> to commit to upgrading.
The path information installed in the registry
(Software\Python\PythonCore under HLKM or HKCU depending on
installation options) is structured according to major.minor release
(e.g., 2.6 vs. 2.7 are distinct), but you're right Windows only
supports one file extension mapping, so by default the last Python to
be installed gets associated with .py/.pyw etc... by default.
But you can optionally disable this during installation. On the
customize screen showing during installation. de-select the "Register
Extensions" option, and the active install won't change any existing
mappings and thus have no impact on your current default installation.
> If there are better ways on Windows to accomplish this, I'd like to
> hear about them. I suppose I could use hardlinks or junctions but
> they're not well supported on most versions of Windows.
If you're still using the basic Windows command prompt or GUI links
then a batch file is the simplest way to go. With something like
Cygwin (which I personally would never do without), then you have a
variety of techniques available including links, shell aliases, etc...
-- David
--Forwarded Message Attachment--
From: vinay_sajip at yahoo.co.uk
To: python-list at python.org
Date: Mon, 5 Jul 2010 23:22:05 -0700
Subject: Re: SMTPHandler and Unicode
On Jul 5, 2:35 pm, Antoine Pitrou <solip... at pitrou.net> wrote:
> > a FileHandler works as expected, the log file being UTF-8 encoded.
>
> Ouch. Implicit encoding sounds like a bad behaviour.
UTF-8 is only used as a fallback in an exception handler, you can use
any supported encoding using the encoding= keyword argument to a
FileHandler.
>
> I suggest you report an issue onhttp://bugs.python.org
Yes, please do that and I will investigate.
Regards,
Vinay Sajip
_________________________________________________________________
Hotmail: Free, trusted and rich email service.
https://signup.live.com/signup.aspx?id=60969
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20100706/de48e226/attachment.html>
More information about the Python-list
mailing list