Re: How to represent a sequence of raw bytes

[Hrvoje Niksic]

"Steven Woody"  writes:

> What's the right type to represent a sequence of raw bytes.  In C,
> we usually do
>
> 1.  char buf[200]  or
> 2.  char buf[] = {0x11, 0x22, 0x33, ... }
>
> What's the equivalent representation for above in Python?

import array
buf = array.array('b', [0x11, 0x22, ...])

It automatically retrieves byte values without having to call ord(),
and it allows changing them.  It also has a C API for getting to the
address of the underlying buffer.
--
http://mail.python.org/mailman/listinfo/python-list

Re: How to represent a sequence of raw bytes

[Chris Rebert]

On Sun, Dec 21, 2008 at 10:56 PM, Steven Woody  wrote:
> On Mon, Dec 22, 2008 at 10:27 AM, Michiel Overtoom  wrote:
>> On Monday 22 December 2008 03:23:03 Steven Woody wrote:
>>
>>> 2.  char buf[] = {0x11, 0x22, 0x33, ... }
>>>
>>> What's the equivalent representation for above in Python?
>>
> buf="\x11\x22\33"
> for b in buf: print ord(b)
>> ...
>> 17
>> 34
>> 27
>
>>
>
> Hi, Michiel
>
> I thing "\x11\x22\x33" in python is not the {0x11, 0x22, 0x33} in C.
> Since, a string in python is immutable, I can _not_ do something like:
>  b[1] = "\x55".
>
> And, how about char buf[200] in my original question?  The intension
> is to allocate 200 undefined bytes in memory. Thanks.

You want the `bytearray` type referred to in PEP 3137
(http://www.python.org/dev/peps/pep-3137/).
However, I believe `bytearray` is only available in Python 3.0

Cheers,
Chris

-- 
Follow the path of the Iguana...
http://rebertia.com
--
http://mail.python.org/mailman/listinfo/python-list

Re: How to represent a sequence of raw bytes

[Tino Wildenhain]

Steven Woody wrote:

On Mon, Dec 22, 2008 at 10:27 AM, Michiel Overtoom  wrote:

On Monday 22 December 2008 03:23:03 Steven Woody wrote:


2.  char buf[] = {0x11, 0x22, 0x33, ... }

What's the equivalent representation for above in Python?

buf="\x11\x22\33"

...


I thing "\x11\x22\x33" in python is not the {0x11, 0x22, 0x33} in C.
Since, a string in python is immutable, I can _not_ do something like:
 b[1] = "\x55".

And, how about char buf[200] in my original question?  The intension
is to allocate 200 undefined bytes in memory. Thanks.


Well in most cases you don't need to do that, instead you could assemble
your stream on the way out based on sequences, generators etc.

Please note that char in your example is just a bit inapropriate (but
common in C) shorthand for unsigned short int. There is no such type
in python so you could use int() if you want to operate on the numeric
value. Depending on your use case a big integer could also serve well
and you can convert it into a byte string.

If you want random access to the bytes, you can use list or array (see 
array module) or, if you want it with much more performance resort

to numpy, scipy, they have arrays similar to C and also much more
numeric datatypes.

Regards
Tino


smime.p7s
Description: S/MIME Cryptographic Signature
--
http://mail.python.org/mailman/listinfo/python-list

Re: How to represent a sequence of raw bytes

[Steven Woody]

On Mon, Dec 22, 2008 at 10:27 AM, Michiel Overtoom  wrote:
> On Monday 22 December 2008 03:23:03 Steven Woody wrote:
>
>> 2.  char buf[] = {0x11, 0x22, 0x33, ... }
>>
>> What's the equivalent representation for above in Python?
>
 buf="\x11\x22\33"
 for b in buf: print ord(b)
> ...
> 17
> 34
> 27

>

Hi, Michiel

I thing "\x11\x22\x33" in python is not the {0x11, 0x22, 0x33} in C.
Since, a string in python is immutable, I can _not_ do something like:
 b[1] = "\x55".

And, how about char buf[200] in my original question?  The intension
is to allocate 200 undefined bytes in memory. Thanks.

Regards,
--
http://mail.python.org/mailman/listinfo/python-list

Re: Are Django/Turbogears too specific?

[Tino Wildenhain]

Philip Semanchuk wrote:
...


I prefer Mako over the other template languages I've seen.


From what I can tell Mako is nearly identical to all other
template languages you might have seen (e.g. PHP style
tags). Thats why I personally would not consider it. Its just
much of a hassle to mix code and design this way.

I prefer TAL (template attribute language, ZPT) [1]
much over the other attempts I've seen ( and I've seen a lot)

Cheers
Tino

[1] http://en.wikipedia.org/wiki/Template_Attribute_Language


smime.p7s
Description: S/MIME Cryptographic Signature
--
http://mail.python.org/mailman/listinfo/python-list

Re: Twisted for non-networking applications

[James Mills]

On Mon, Dec 22, 2008 at 3:25 PM, RajNewbie  wrote:
> I was unable to see documentation explaining this - so asking again.

Documentation is available here:
http://trac.softcircuit.com.au/circuits/wiki/docs
And here: pydoc circuits

The code itself is heavily documented. I'm still
writing better online references, tutorials
and what not ... :) Please see the examples/

> Suppose the event handlers in the component is doing blocking work,
> how is it handled?

You have a few options.
1. Do your work in a thread.
2. Do your work in a process.

You could utilize the Worker component for
such things. I'm also building a Process
component that uses the multiprocessing module.

> I went through ciruits.core, but was unable to understand exactly how
> blocking mechanisms are handled.

They aren't. It's up to you to handle such
situations. If your "event-handler" blocks,
everything, it will block every other event
handler from being processes.

In what situation would you have this ?
I'm curious :)

> My scenario is as follows:
> I have 4 loops, 1 small and high priority, 3 quite large and blocking
> (takes upto 3 seconds) and comparatively low priority.
> The small loops goes through everytime and does some work - and
> optionally uses the data sent by the other 3 loops.
> I do not want the smaller loop to get blocked by the other loops.

This sounds complex :) What is your application ?
What's being processes ?

> So, if the event handler does blocking work, can that cause the whole
> loop to block?

Yes. If you decide to use circuits, I suggest
you restructure your program. Try to do
your work (if it's blocking) in Worker components (threads).

cheers
James
--
http://mail.python.org/mailman/listinfo/python-list

Discount (paypal) www.ebuyvip.com nfl jersey ugg boots

[Jacky]

Hi friend

Thanks for your reply.

The current stock list with the available jerseys and sizea in the add
annex, pls check it.

and the jerseys pictures you can check my ablum : http://likenfl.photo.163.com
. the moq

order: 10 pcs  the price : $20 inc shipping fee and tax.If you worry
do businees with me

first. and cann't trust me, the payment we can by paypal. that we all
can trust other.
If you have any questions pls tell me , i will give you a satisfaction
answer.
Hope we can have a nice and long term cooperation.
UGG BOOTS: $45 NFL JERSEY: $20

Website: www.ebuyvip.com
MSN: ebuy...@hotmail.com

Waiting for your good news.


Best Regard


Jarky
--
http://mail.python.org/mailman/listinfo/python-list

Re: Twisted for non-networking applications

[RajNewbie]

On Dec 22, 3:26 am, "James Mills" 
wrote:
> On Mon, Dec 22, 2008 at 4:27 AM, Kottiyath  wrote:
> > Hi all,
> >   Is it a good idea to use Twisted inside my application, even though
> > it has no networking part in it?
> >   Basically, my application needs lots of parallel processing - but I
> > am rather averse to using threads - due to myraid issues it can cause.
> > So, I was hoping to use a reactor pattern to avoid the threads. I am
> > using twisted in another part of the application for networking, so I
> > was hoping to use the same for the non-networking part for reusing the
> > reactor pattern.
> >   If somebody can help me on this, it would be very helpful.
>
> Alternatively you could give circuits (1)
> a go. It _can_ be a nice alternative to
> Twisted and isn't necessarily focused on
> Networking applications.
>
> cheers
> James
>
> 1.http://trac.softcircuit.com.au/circuits/

I was unable to see documentation explaining this - so asking again.
Suppose the event handlers in the component is doing blocking work,
how is it handled?
I went through ciruits.core, but was unable to understand exactly how
blocking mechanisms are handled.
My scenario is as follows:
I have 4 loops, 1 small and high priority, 3 quite large and blocking
(takes upto 3 seconds) and comparatively low priority.
The small loops goes through everytime and does some work - and
optionally uses the data sent by the other 3 loops.
I do not want the smaller loop to get blocked by the other loops.

So, if the event handler does blocking work, can that cause the whole
loop to block?
--
http://mail.python.org/mailman/listinfo/python-list

www.iofferkicks.com china cheap wholesale nike shoes,air jordan shoes,air force one shoes.

[iofferkicks...@gmail.com]

Get Nike Shoes at Super Cheap Prices
Discount Nike air jordans  (www.iofferkicks.com)
Discount Nike Air Max 90 Sneakers  (www.iofferkicks.com)
Discount Nike Air Max 91 Supplier  (www.iofferkicks.com)
Discount Nike Air Max 95 Shoes Supplier  (www.iofferkicks.com)
Discount Nike Air Max 97 Trainers  (www.iofferkicks.com)
Discount Nike Air Max 2003 Wholesale  (www.iofferkicks.com)
Discount Nike Air Max 2004 Shoes Wholesale
(www.iofferkicks.com)
Discount Nike Air Max 2005 Shop  (www.iofferkicks.com)
Discount Nike Air Max 2006 Shoes Shop  (www.iofferkicks.com)
Discount Nike Air Max 360 Catalogs  (www.iofferkicks.com)
Discount Nike Air Max Ltd Shoes Catalogs  (www.iofferkicks.com)
Discount Nike Air Max Tn Men's Shoes  (www.iofferkicks.com)
Discount Nike Air Max Tn 2 Women's Shoes  (www.iofferkicks.com)
Discount Nike Air Max Tn 3 Customize  (www.iofferkicks.com)
Discount Nike Air Max Tn 4 Shoes Customize
( www.iofferkicks.com)
Discount Nike Air Max Tn 6 Supply  (www.iofferkicks.com)
Discount Nike Shox NZ Shoes Supply  (www.iofferkicks.com)
Discount Nike Shox OZ Sale  (www.iofferkicks.com)
Discount Nike Shox TL Store  (www.iofferkicks.com)
Discount Nike Shox TL 2 Shoes Store (www.iofferkicks.com)
Discount Nike Shox TL 3 Distributor (www.iofferkicks.com)
Discount Nike Shox Bmw Shoes Distributor  (www.iofferkicks.com)
Discount Nike Shox Elite Shoes Manufacturer
(www.iofferkicks.com)
Discount Nike Shox Monster Manufacturer  (www.iofferkicks.com)
Discount Nike Shox R4 Running Shoes  (www.iofferkicks.com)
Discount Nike Shox R5 Mens Shoes  (www.iofferkicks.com)
Discount Nike Shox Ride Womens Shoes (www.iofferkicks.com)
Discount Nike Shox Rival Shoes Wholesaler  (www.iofferkicks.com)
Discount Nike Shox Energia Wholesaler  (www.iofferkicks.com)
Discount Nike Shox LV Sneaker  (www.iofferkicks.com)
Discount Nike Shox Turbo Suppliers  (www.iofferkicks.com)
Discount Nike Shox Classic Shoes Suppliers
(www.iofferkicks.com)
Discount Nike Shox Dendara Trainer  (www.iofferkicks.com)
Discount Nike Air Jordan 1 Seller  (www.iofferkicks.com)
Discount Nike Air Jordan 2 Shoes Seller  (www.iofferkicks.com)
Discount Nike Air Jordan 3 Collection  (www.iofferkicks.com)
Discount Nike Air Jordan 4 Shoes Collection
(www.iofferkicks.com)
Discount Nike Air Jordan 5 Chaussure Shoes
(www.iofferkicks.com)
Discount Nike Air Jordan 6 Catalog  (www.iofferkicks.com)
Discount Nike Air Jordan 7 Shoes Catalog  (www.iofferkicks.com)
Discount Nike Air Jordan 8 Customized  (www.iofferkicks.com)
Discount Nike Air Jordan 9 Shoes Customized
(www.iofferkicks.com)
Discount Nike Air Jordan 10 Wholesalers  (www.iofferkicks.com)
Discount Nike Jordan 11 Shoes Wholesalers (www.iofferkicks.com)
Discount Nike Air Jordan 12 Factory  (www.iofferkicks.com)
Discount Nike Air Jordan 13 Shoes Factory (www.iofferkicks.com)
Discount Nike Air Jordan 14 Shoes Sell  (www.iofferkicks.com)
Discount Nike Air Jordan 16 Exporter  (www.iofferkicks.com)
Discount Nike Air Jordan 17 Shoes Exporter
(www.iofferkicks.com)
Discount Nike Air Jordan 18 Offer  (www.iofferkicks.com)
Discount Nike Air Jordan 19 Shoes Offer  (www.iofferkicks.com)
Discount Nike Air Jordan 20 Manufacture  (www.iofferkicks.com)
Discount Nike Jordan 21 Shoes Manufacture  (www.iofferkicks.com)
EMAIL:iofferki...@gmail.com
MSN :iofferki...@msn.com
--
http://mail.python.org/mailman/listinfo/python-list

www.iofferkicks.com china cheap wholesale nike shoes,air jordan shoes,air force one shoes.

[www.iofferkicks.com]

Get Nike Shoes at Super Cheap Prices
Discount Nike air jordans  (www.iofferkicks.com)
Discount Nike Air Max 90 Sneakers  (www.iofferkicks.com)
Discount Nike Air Max 91 Supplier  (www.iofferkicks.com)
Discount Nike Air Max 95 Shoes Supplier  (www.iofferkicks.com)
Discount Nike Air Max 97 Trainers  (www.iofferkicks.com)
Discount Nike Air Max 2003 Wholesale  (www.iofferkicks.com)
Discount Nike Air Max 2004 Shoes Wholesale
(www.iofferkicks.com)
Discount Nike Air Max 2005 Shop  (www.iofferkicks.com)
Discount Nike Air Max 2006 Shoes Shop  (www.iofferkicks.com)
Discount Nike Air Max 360 Catalogs  (www.iofferkicks.com)
Discount Nike Air Max Ltd Shoes Catalogs  (www.iofferkicks.com)
Discount Nike Air Max Tn Men's Shoes  (www.iofferkicks.com)
Discount Nike Air Max Tn 2 Women's Shoes  (www.iofferkicks.com)
Discount Nike Air Max Tn 3 Customize  (www.iofferkicks.com)
Discount Nike Air Max Tn 4 Shoes Customize
( www.iofferkicks.com)
Discount Nike Air Max Tn 6 Supply  (www.iofferkicks.com)
Discount Nike Shox NZ Shoes Supply  (www.iofferkicks.com)
Discount Nike Shox OZ Sale  (www.iofferkicks.com)
Discount Nike Shox TL Store  (www.iofferkicks.com)
Discount Nike Shox TL 2 Shoes Store (www.iofferkicks.com)
Discount Nike Shox TL 3 Distributor (www.iofferkicks.com)
Discount Nike Shox Bmw Shoes Distributor  (www.iofferkicks.com)
Discount Nike Shox Elite Shoes Manufacturer
(www.iofferkicks.com)
Discount Nike Shox Monster Manufacturer  (www.iofferkicks.com)
Discount Nike Shox R4 Running Shoes  (www.iofferkicks.com)
Discount Nike Shox R5 Mens Shoes  (www.iofferkicks.com)
Discount Nike Shox Ride Womens Shoes (www.iofferkicks.com)
Discount Nike Shox Rival Shoes Wholesaler  (www.iofferkicks.com)
Discount Nike Shox Energia Wholesaler  (www.iofferkicks.com)
Discount Nike Shox LV Sneaker  (www.iofferkicks.com)
Discount Nike Shox Turbo Suppliers  (www.iofferkicks.com)
Discount Nike Shox Classic Shoes Suppliers
(www.iofferkicks.com)
Discount Nike Shox Dendara Trainer  (www.iofferkicks.com)
Discount Nike Air Jordan 1 Seller  (www.iofferkicks.com)
Discount Nike Air Jordan 2 Shoes Seller  (www.iofferkicks.com)
Discount Nike Air Jordan 3 Collection  (www.iofferkicks.com)
Discount Nike Air Jordan 4 Shoes Collection
(www.iofferkicks.com)
Discount Nike Air Jordan 5 Chaussure Shoes
(www.iofferkicks.com)
Discount Nike Air Jordan 6 Catalog  (www.iofferkicks.com)
Discount Nike Air Jordan 7 Shoes Catalog  (www.iofferkicks.com)
Discount Nike Air Jordan 8 Customized  (www.iofferkicks.com)
Discount Nike Air Jordan 9 Shoes Customized
(www.iofferkicks.com)
Discount Nike Air Jordan 10 Wholesalers  (www.iofferkicks.com)
Discount Nike Jordan 11 Shoes Wholesalers (www.iofferkicks.com)
Discount Nike Air Jordan 12 Factory  (www.iofferkicks.com)
Discount Nike Air Jordan 13 Shoes Factory (www.iofferkicks.com)
Discount Nike Air Jordan 14 Shoes Sell  (www.iofferkicks.com)
Discount Nike Air Jordan 16 Exporter  (www.iofferkicks.com)
Discount Nike Air Jordan 17 Shoes Exporter
(www.iofferkicks.com)
Discount Nike Air Jordan 18 Offer  (www.iofferkicks.com)
Discount Nike Air Jordan 19 Shoes Offer  (www.iofferkicks.com)
Discount Nike Air Jordan 20 Manufacture  (www.iofferkicks.com)
Discount Nike Jordan 21 Shoes Manufacture  (www.iofferkicks.com)
EMAIL:iofferki...@gmail.com
MSN :iofferki...@msn.com
--
http://mail.python.org/mailman/listinfo/python-list

Re: Are Django/Turbogears too specific?

[J Kenneth King]

Gilles Ganault  writes:

> Hi
>
> I'd like to rewrite a Web 2.0 PHP application in Python with AJAX, and
> it seems like Django and Turbogears are the frameworks that have the
> most momentum.
>
> I'd like to use this opportunity to lower the load on servers, as the
> PHP application wasn't built to fit the number of users hammering the
> servers now.
>
> I'm concerned, though, that these frameworks they may be too specific
> to the tasks they were originally developped for (news articles,
> AFAIK). Do you think I should just use eg. CherryPy and some basic
> AJAX?
>
> Thank you for any feedback.

They're not "specific" in the sense that they only build certain types
of applications. However, they do package their own batteries and
expect applications to be designed a certain way. As long as you drink
the kool-aid, everything is smooth sailing. That's what any
"framework" banks on -- being useful to 85% of the web applications;
not all. Even if they advertise themselves as such, it's just not
true.

My suggestion is web.py -- It too has its own set of conventions and
philosophies, but in my experience it is the most loosely coupled in
terms of internal dependencies. Import exactly what you want to use
and deploy it the way that suits you. It gives you batteries but you
have to pick and choose how to put the pieces together. Therefore, it
takes a little longer to get running, but IMO that is the most
flexibility you can ask for without writing your own servers and
frameworks.

Cheers.
--
http://mail.python.org/mailman/listinfo/python-list

Re: New Python 3.0 string formatting - really necessary?

[MRAB]

Aaron Brady wrote:

On Dec 21, 6:14 pm, MRAB  wrote:

Aaron Brady wrote:

On Dec 21, 10:58 am, MRAB  wrote:

Aaron Brady wrote:

On Dec 21, 10:31 am, MRAB  wrote:

snip

The original format is a string. The result of '%' is a string if
there's only 1 placeholder to fill, or a (partial) format object (class
"Format"?) if there's more than one. Similarly, the format object
supports '%'. The result of '%' is a string if there's only 1
placeholder to fill, or a new (partial) format object if there's more
than one.
 >>> f = "%r %i"
 >>> type(f)

 >>> f = f % (2, 3, 4)
 >>> type(f)

 >>> f = f % 1
 >>> type(f)


Alright, so how are you handling:

f= "%s %i"
type( f )



f= f% '%i'  #now '%i %i'
type( f )



f= f% 1
type( f )

?
In other words, are you slipping '1' in to the very first available
slot, or the next, after the location of the prior?

Let's assume that Format objects display their value like the equivalent
string format:
 >>> f = "%r %i"
 >>> f
'%r %i'
 >>> f = f % (2, 3, 4)
 >>> f

 >>> f = f % 1
 >>> f
'(2, 3, 4) 1'
 >>> f = "%s %i"
 >>> f
'%s %i'
 >>> f = f % '%i'
 >>> f

 >>> f = f % 1
 >>> f
'%%i 1'

I assume you meant '%i 1' since there are no more flags in f, and it's
returned to a regular string.

Correct.


'f %= 1' doesn't work any more as in-place modulo, since one time, 'f'
is a Format object, the other, 'f' is a string.  Just raise an
exception for that (or assign to __class__ IINM if I'm not mistaken).

All assignments rebind, even the augmented form:

 >>> class C1(object):
def __mod__(self, value):
return C2()

 >>> class C2(object):
def __mod__(self, value):
return C2()

 >>> f = C1()
 >>> f
<__main__.C1 object at 0x00D144F0>
 >>> f % 0
<__main__.C2 object at 0x00D143F0>
 >>> f %= 0
 >>> f
<__main__.C2 object at 0x00D145B0>




Actually, the class you showed is kind of nifty.  Tuples are correctly
interpolated.  I think on the whole you'll use more parenthesis, since
each term in the tuple appears separately, and might be an expression
(have a lower-precedence op.), as well as more modulo signs.
You can currently do-it-yourself, you just need a constructor in the
format string.

f = Format("%r %i")
type(f)



f = f % (2, 3, 4)
type(f)


Or, as someone suggested earlier, a new literal marking:

Yes, I suggested that earlier, but it isn't needed because you can
create a format object with "Format(string)". However, most of the time
you won't bother to create a format object explicitly because of:

class str(object):
 def __mod__(self, value):
 return Format(self) % value


f = f"%r %i"
type(f)



 >>> # Explicitly
 >>> f = Format("%r %i")
 >>> f

 >>> f % (2, 3, 4)

 >>>
 >>> # Implicitly, relying on the __mod__ method of str
 >>> f = "%r %i"
 >>> f
'%r %i'
 >>> f % (2, 3, 4)


I'd also like to add that there's nothing to prevent format objects from
having other methods where multiple placeholders can be filled in one call:

 >>> # By position
 >>> f = Format("%r %i")
 >>> f

 >>> f.fill([(2, 3, 4), 1])
'(2, 3, 4) 1'
 >>>
 >>> # By name
 >>> f = Format("%{tuple}r %{int}i")
 >>> f

 >>> f.fill({"tuple": (2, 3, 4), "int": 1})
'(2, 3, 4) 1'


You're choosing to favor the '.chain()' method over the '.fill()'
method for the behavior of '%'.  I don't think you've justified it
though.


Format( "%r %i" ).chain( ( 2, 3, 4 ) ).chain( 0 )

'(2, 3, 4) 0'

Format( "%r %i" ).fill( ( 2, 3, 4 ), 0 )

'(2, 3, 4) 0'

Plus, I almost think we've almost attained defeating the purpose.

The disadvantage of the chaining method is that it's positional, 
left-to-right. For the purposes of i18n you want tagged placeholders, 
whether they be integers or names. I think... OK, if the placeholders 
include a positional tag, eg "%(0)s %(1)s", then they could be filled in 
according to _that_ order. Not sure about named placeholders, though. 
Perhaps, like at present, if a dict is given to a format with named 
placeholders then several placeholders could be filled, the problem 
being how to fill a _single_ named placeholder with a dict.

--
http://mail.python.org/mailman/listinfo/python-list

Re: How to represent a sequence of raw bytes

[Michiel Overtoom]

On Monday 22 December 2008 03:23:03 Steven Woody wrote:

> 2.  char buf[] = {0x11, 0x22, 0x33, ... }
>
> What's the equivalent representation for above in Python?

>>> buf="\x11\x22\33"
>>> for b in buf: print ord(b)
...
17
34
27
>>>


Greetings, 

-- 
"The ability of the OSS process to collect and harness 
the collective IQ of thousands of individuals across 
the Internet is simply amazing." - Vinod Vallopillil 
http://www.catb.org/~esr/halloween/halloween4.html
--
http://mail.python.org/mailman/listinfo/python-list

How to represent a sequence of raw bytes

[Steven Woody]

Hi,

What's the right type to represent a sequence of raw bytes.  In C, we usually do

1.  char buf[200]  or
2.  char buf[] = {0x11, 0x22, 0x33, ... }

What's the equivalent representation for above in Python?

Thanks.

-
narke
--
http://mail.python.org/mailman/listinfo/python-list

Re: New Python 3.0 string formatting - really necessary?

[Aaron Brady]

On Dec 21, 6:14 pm, MRAB  wrote:
> Aaron Brady wrote:
> > On Dec 21, 10:58 am, MRAB  wrote:
> >> Aaron Brady wrote:
> >>> On Dec 21, 10:31 am, MRAB  wrote:
> > snip
>  The original format is a string. The result of '%' is a string if
>  there's only 1 placeholder to fill, or a (partial) format object (class
>  "Format"?) if there's more than one. Similarly, the format object
>  supports '%'. The result of '%' is a string if there's only 1
>  placeholder to fill, or a new (partial) format object if there's more
>  than one.
>   >>> f = "%r %i"
>   >>> type(f)
>  
>   >>> f = f % (2, 3, 4)
>   >>> type(f)
>  
>   >>> f = f % 1
>   >>> type(f)
>  
> >>> Alright, so how are you handling:
> >> f= "%s %i"
> >> type( f )
> >>> 
> >> f= f% '%i'  #now '%i %i'
> >> type( f )
> >>> 
> >> f= f% 1
> >> type( f )
> >>> ?
> >>> In other words, are you slipping '1' in to the very first available
> >>> slot, or the next, after the location of the prior?
> >> Let's assume that Format objects display their value like the equivalent
> >> string format:
>
> >>  >>> f = "%r %i"
> >>  >>> f
> >> '%r %i'
> >>  >>> f = f % (2, 3, 4)
> >>  >>> f
> >> 
> >>  >>> f = f % 1
> >>  >>> f
> >> '(2, 3, 4) 1'
>
> >>  >>> f = "%s %i"
> >>  >>> f
> >> '%s %i'
> >>  >>> f = f % '%i'
> >>  >>> f
> >> 
> >>  >>> f = f % 1
> >>  >>> f
> >> '%%i 1'
>
> > I assume you meant '%i 1' since there are no more flags in f, and it's
> > returned to a regular string.
>
> Correct.
>
> > 'f %= 1' doesn't work any more as in-place modulo, since one time, 'f'
> > is a Format object, the other, 'f' is a string.  Just raise an
> > exception for that (or assign to __class__ IINM if I'm not mistaken).
>
> All assignments rebind, even the augmented form:
>
>  >>> class C1(object):
>         def __mod__(self, value):
>                 return C2()
>
>  >>> class C2(object):
>         def __mod__(self, value):
>                 return C2()
>
>  >>> f = C1()
>  >>> f
> <__main__.C1 object at 0x00D144F0>
>  >>> f % 0
> <__main__.C2 object at 0x00D143F0>
>  >>> f %= 0
>  >>> f
> <__main__.C2 object at 0x00D145B0>
>
>
>
> > Actually, the class you showed is kind of nifty.  Tuples are correctly
> > interpolated.  I think on the whole you'll use more parenthesis, since
> > each term in the tuple appears separately, and might be an expression
> > (have a lower-precedence op.), as well as more modulo signs.
>
> > You can currently do-it-yourself, you just need a constructor in the
> > format string.
>
>  f = Format("%r %i")
>  type(f)
> > 
>  f = f % (2, 3, 4)
>  type(f)
> > 
>
> > Or, as someone suggested earlier, a new literal marking:
>
> Yes, I suggested that earlier, but it isn't needed because you can
> create a format object with "Format(string)". However, most of the time
> you won't bother to create a format object explicitly because of:
>
> class str(object):
>      def __mod__(self, value):
>          return Format(self) % value
>
>  f = f"%r %i"
>  type(f)
> > 
>
>  >>> # Explicitly
>  >>> f = Format("%r %i")
>  >>> f
> 
>  >>> f % (2, 3, 4)
> 
>  >>>
>  >>> # Implicitly, relying on the __mod__ method of str
>  >>> f = "%r %i"
>  >>> f
> '%r %i'
>  >>> f % (2, 3, 4)
> 
>
> I'd also like to add that there's nothing to prevent format objects from
> having other methods where multiple placeholders can be filled in one call:
>
>  >>> # By position
>  >>> f = Format("%r %i")
>  >>> f
> 
>  >>> f.fill([(2, 3, 4), 1])
> '(2, 3, 4) 1'
>  >>>
>  >>> # By name
>  >>> f = Format("%{tuple}r %{int}i")
>  >>> f
> 
>  >>> f.fill({"tuple": (2, 3, 4), "int": 1})
> '(2, 3, 4) 1'

You're choosing to favor the '.chain()' method over the '.fill()'
method for the behavior of '%'.  I don't think you've justified it
though.

>>> Format( "%r %i" ).chain( ( 2, 3, 4 ) ).chain( 0 )
'(2, 3, 4) 0'
>>> Format( "%r %i" ).fill( ( 2, 3, 4 ), 0 )
'(2, 3, 4) 0'

Plus, I almost think we've almost attained defeating the purpose.
--
http://mail.python.org/mailman/listinfo/python-list

Re: New Python 3.0 string formatting - really necessary?

[James Mills]

On Mon, Dec 22, 2008 at 11:37 AM, alex23  wrote:
> On Dec 21, 10:11 am, r  wrote:
>> Most of the complaints i hear are the redundant use of self.
>> Which I lamented about but have become accustom(brainwashed) to it. I
>> would remove this if it where up to me.
>
> It's a shame Python wasn't released under some kind of license, one
> that allowed its source to be, say, "opened" and modified. Otherwise
> you would just implement this yourself and submit patches, right?

+1 :)
--
http://mail.python.org/mailman/listinfo/python-list

Re: Namespaces, multiple assignments, and exec()

[John O'Hagan]

On Sat, 20 Dec 2008, John O'Hagan wrote:
> On Sat, 20 Dec 2008, Terry Reedy wrote:
> > John O'Hagan wrote:
> > > I have a lot of repetitive assignments to make, within a generator,
> > > that use a function outside the generator:
> > >
> > > var1 = func("var1", args)
> > > var2 = func("var2", args)
> > > var3 = func("var3", args)
> > > etc...
> > >
> > > In each case the args are identical, but the first argument is a string
> > > of the name being assigned. It works fine but I'd like to reduce the
> > > clutter by doing the assignments in a loop. I've tried using exec():
> > >
> > > for name in name_string_list:
> > > exec(name + ' = func(\"' + name + '\", args)')
> > >
> > > but in the local namespace it doesn't understand func(), and if I give
> > > it globals() it doesn't understand the args, which come from within the
> > > generator.
> > >
> > > What's a good way to do this kind of thing?
> >
> > Put everything in your own namespace
> >
> > myvars={}
> > for name in namelist:
> >myvars[name]=func(name,args)
>
> Likely I'm missing something, but don't I still have to do
>
> var1 = myvars['var1']
> var2 = myvars['var2']
> var3 = myvars['var3']
> ...etc.
>
> to make the assignments?

And of course I am missing the fact that I can now do the exec loop over 
myvars{} in the local namespace.

Doing this, however, exposed some behaviour that surprises me. Inside my 
generator, doing:

exec('foo = 7') in locals()
print foo
foo = 3

produces an UnboundLocalError. In case it's relevant, the error I get inside 
the generator if I don't specify local()s is:

SyntaxError: unqualified exec is not allowed in function 'sequence_engine' it 
contains a nested function with free variables

But doing the same thing in a simple test generator, even if it calls outside 
functions, works as I expect. 

Removing any subsequent reassignments of the same name fixes the error, and as 
it happens I can do this, but I'm curious, without me posting the whole 
generator (it's long), why doesn't the above exec() assignment work in that 
context? 

Thanks,

John






--
http://mail.python.org/mailman/listinfo/python-list

Re: Threads, forks, multiplexing - oh my

[James Mills]

On Mon, Dec 22, 2008 at 11:36 AM, Thomas Raef  wrote:
> I now want to run multiple instances of this program on a client, after
> receiving the command line and args from a broker, dispatcher, whatever you
> want to call it.

You can use the subprocess module.

> I've read where forks will run programs but they replace the calling program
> – is that correct? Am I reading that right? If so, then my client program
> will have to use forks so it can run a program. Then are threads to run
> functions and not full-fledged programs?

Forking creates a clone/child
process of the parent.

You probably want os.system
or subprocess.

> When, if ever, would I want to look at implementing multiplexing?

Single-process multiplexing (think event-driven)
can often be far better in terms of performance.

--JamesMills
--
http://mail.python.org/mailman/listinfo/python-list

Re: Read an image from a URL and write it to the browser

[Steve Holden]

McCoy Fan wrote:
> On Dec 21, 7:25 am, Peter Otten <__pete...@web.de> wrote:
>> McCoy Fan wrote:
>>> I want to do something simple: read an image from an image URL and
>>> write the image to the browser in CGI style.
>>> I wrote a CGI script to do this (I'm new to Python) and got the
>>> following error:
>>> "FancyURLopener instance has no attribute 'tempcache'" in >> method FancyURLopener.__del__ of >> I have no idea what that error means and neither does Google.
>>> Any idea where I went wrong in the code below?
>>> import urllib
>>> urlString = "http://www.google.com/google_logo.jpg";
>>> imgStream = urllib.urlopen(urlString)
>>> imgBuffer = imgStream.read()
>>> imgStream.close()
>>> print "Content-Type: image/jpeg"
>>> print
>>> print imgBuffer
>> Your script runs without error here, but I can  provoke the attribute error
>> by passing an invalid proxies argument to urlopen():
>>
>> $ python -c"import urllib; urllib.urlopen('whatever', proxies=42)"
>> Traceback (most recent call last):
>>   File "", line 1, in 
>>   File "/usr/lib/python2.5/urllib.py", line 75, in urlopen
>> opener = FancyURLopener(proxies=proxies)
>>   File "/usr/lib/python2.5/urllib.py", line 609, in __init__
>> URLopener.__init__(self, *args, **kwargs)
>>   File "/usr/lib/python2.5/urllib.py", line 117, in __init__
>> assert hasattr(proxies, 'has_key'), "proxies must be a mapping"
>> AssertionError: proxies must be a mapping
>> Exception exceptions.AttributeError: "FancyURLopener instance has no
>> attribute 'tempcache'" in > > ignored
>>
>> Please post your complete traceback, Python version, and OS to allow for a
>> more detailed diagnosis.
>>
>> You can also try to run your script with
>>
>>> imgStream = urllib.urlopen(urlString)
>> changed to
>>
>> imgStream = urllib.urlopen(urlString, proxies={})
>>
>> to bypass the code in which I suppose the failure to occur.
>>
>> Peter
> 
> I appreciate your response. Thank you.
> 
> After reading your reply, I realized this must be related to the fact
> that I am running this script on Google App Engine.
> 
> It turns out, App Engine does not allow direct socket communication so
> urllib is not allowed.
> 
> Instead they provide their own library called urlfetch. So my script
> should look something like this:
> 
> from google.appengine.api import urlfetch
> print 'Content-Type: text/plain'
> print ''
> result = urlfetch.fetch('http://www.google.com/google_logo.jpg')
> print result.content
> 
> I haven't been able to get it to work yet but at least I'm heading in
> the right direction now. I'll keep digging. Thanks!

You might also want to bear in mind that at least for me the content
that this URL returns is HTML with embedded javascript, and not the JPEG
you were expecting. That's because the URL gives a 404 response.

This might be a seasonal thing: right now they are showing a "Happy
Holidays" motif on their front page.

regards
 Steve
-- 
Steve Holden+1 571 484 6266   +1 800 494 3119
Holden Web LLC  http://www.holdenweb.com/

--
http://mail.python.org/mailman/listinfo/python-list

Threads, forks, multiplexing - oh my

[Thomas Raef]

I have a program that was created by someone else and it does it's job
beautifully.

 

I now want to run multiple instances of this program on a client, after
receiving the command line and args from a broker, dispatcher, whatever
you want to call it.

 

This dispatcher will listen for a connection from a client and then pass
this client the command line to run this python program. The client will
receive the command line, run the python program and then go get another
one to run. It might run this program 4 times simultaneously (or so it
will seem).

 

I've read where forks will run programs but they replace the calling
program - is that correct? Am I reading that right? If so, then my
client program will have to use forks so it can run a program. Then are
threads to run functions and not full-fledged programs?

 

When, if ever, would I want to look at implementing multiplexing?

 

Please help me clarify and if possible give me some direction for this.

 

Thank you in advance.

 

Thomas J. Raef

www.ebasedsecurity.com

www.wewatchyourwebsite.com

"We Watch Your Website because - you don't"

 

--
http://mail.python.org/mailman/listinfo/python-list

Re: New Python 3.0 string formatting - really necessary?

[alex23]

On Dec 21, 10:11 am, r  wrote:
> Most of the complaints i hear are the redundant use of self.
> Which I lamented about but have become accustom(brainwashed) to it. I
> would remove this if it where up to me.

It's a shame Python wasn't released under some kind of license, one
that allowed its source to be, say, "opened" and modified. Otherwise
you would just implement this yourself and submit patches, right?

--
http://mail.python.org/mailman/listinfo/python-list

Re: Beep

[Jeffrey Barish]

Chris Rebert wrote:
> 
> Is the 'pcspkr' kernel module built and loaded?

Yes.  And I should have mentioned that I get sound from Ubuntu applications
that produce sound.
-- 
Jeffrey Barish

--
http://mail.python.org/mailman/listinfo/python-list

Re: Beep

[Stef Mientki]

Jeffrey Barish wrote:

I use sys.stdout.write('\a') to beep.  It works fine on Kubuntu, but not on
two other platforms (one of which is Ubuntu).  I presume that the problem
is due to a system configuration issue.  Can someone point me in the right
direction?  Thanks.
  

I started a thread about this issue acouple of weeks ago, look for
 "how to get a beep, OS independent ?"

The best way seems to use something like PyGame.

cheers,
Stef
--
http://mail.python.org/mailman/listinfo/python-list

Re: Beep

[Chris Rebert]

On Sun, Dec 21, 2008 at 4:16 PM, Jeffrey Barish
 wrote:
> I use sys.stdout.write('\a') to beep.  It works fine on Kubuntu, but not on
> two other platforms (one of which is Ubuntu).  I presume that the problem
> is due to a system configuration issue.  Can someone point me in the right
> direction?  Thanks.

Is the 'pcspkr' kernel module built and loaded?

Cheers,
Chris

-- 
Follow the path of the Iguana...
http://rebertia.com
--
http://mail.python.org/mailman/listinfo/python-list

Beep

[Jeffrey Barish]

I use sys.stdout.write('\a') to beep.  It works fine on Kubuntu, but not on
two other platforms (one of which is Ubuntu).  I presume that the problem
is due to a system configuration issue.  Can someone point me in the right
direction?  Thanks.
-- 
Jeffrey Barish

--
http://mail.python.org/mailman/listinfo/python-list

Re: New Python 3.0 string formatting - really necessary?

[MRAB]

Aaron Brady wrote:

On Dec 21, 10:58 am, MRAB  wrote:

Aaron Brady wrote:

On Dec 21, 10:31 am, MRAB  wrote:

snip

The original format is a string. The result of '%' is a string if
there's only 1 placeholder to fill, or a (partial) format object (class
"Format"?) if there's more than one. Similarly, the format object
supports '%'. The result of '%' is a string if there's only 1
placeholder to fill, or a new (partial) format object if there's more
than one.
 >>> f = "%r %i"
 >>> type(f)

 >>> f = f % (2, 3, 4)
 >>> type(f)

 >>> f = f % 1
 >>> type(f)


Alright, so how are you handling:

f= "%s %i"
type( f )



f= f% '%i'  #now '%i %i'
type( f )



f= f% 1
type( f )

?
In other words, are you slipping '1' in to the very first available
slot, or the next, after the location of the prior?

Let's assume that Format objects display their value like the equivalent
string format:

 >>> f = "%r %i"
 >>> f
'%r %i'
 >>> f = f % (2, 3, 4)
 >>> f

 >>> f = f % 1
 >>> f
'(2, 3, 4) 1'
 >>>
 >>> f = "%s %i"
 >>> f
'%s %i'
 >>> f = f % '%i'
 >>> f

 >>> f = f % 1
 >>> f
'%%i 1'


I assume you meant '%i 1' since there are no more flags in f, and it's
returned to a regular string.


Correct.


'f %= 1' doesn't work any more as in-place modulo, since one time, 'f'
is a Format object, the other, 'f' is a string.  Just raise an
exception for that (or assign to __class__ IINM if I'm not mistaken).


All assignments rebind, even the augmented form:

>>> class C1(object):
def __mod__(self, value):
return C2()

>>> class C2(object):
def __mod__(self, value):
return C2()


>>> f = C1()
>>> f
<__main__.C1 object at 0x00D144F0>
>>> f % 0
<__main__.C2 object at 0x00D143F0>
>>> f %= 0
>>> f
<__main__.C2 object at 0x00D145B0>


Actually, the class you showed is kind of nifty.  Tuples are correctly
interpolated.  I think on the whole you'll use more parenthesis, since
each term in the tuple appears separately, and might be an expression
(have a lower-precedence op.), as well as more modulo signs.

You can currently do-it-yourself, you just need a constructor in the
format string.


f = Format("%r %i")
type(f)



f = f % (2, 3, 4)
type(f)



Or, as someone suggested earlier, a new literal marking:

Yes, I suggested that earlier, but it isn't needed because you can 
create a format object with "Format(string)". However, most of the time 
you won't bother to create a format object explicitly because of:


class str(object):
def __mod__(self, value):
return Format(self) % value


f = f"%r %i"
type(f)





>>> # Explicitly
>>> f = Format("%r %i")
>>> f

>>> f % (2, 3, 4)

>>>
>>> # Implicitly, relying on the __mod__ method of str
>>> f = "%r %i"
>>> f
'%r %i'
>>> f % (2, 3, 4)


I'd also like to add that there's nothing to prevent format objects from 
having other methods where multiple placeholders can be filled in one call:


>>> # By position
>>> f = Format("%r %i")
>>> f

>>> f.fill([(2, 3, 4), 1])
'(2, 3, 4) 1'
>>>
>>> # By name
>>> f = Format("%{tuple}r %{int}i")
>>> f

>>> f.fill({"tuple": (2, 3, 4), "int": 1})
'(2, 3, 4) 1'
--
http://mail.python.org/mailman/listinfo/python-list

Re: HMAC with RIPEMD-160

[Chris Rebert]

On Sun, Dec 21, 2008 at 4:21 AM, Kless  wrote:
> Is there any way of use HMAC with RIPEMD-160?
>
> Since that to create a ripemd-160 hash there is to use:
>h = hashlib.new('ripemd160')
> it looks that isn't possible
>
> For HMAC-SHA256 would be:
> -
> import hashlib
> import hmac
>
> hm = hmac.new('key', msg='message', digestmod=hashlib.sha256)

Untested, but should work according to the docs:
hm = hmac.new('key', msg='message', digestmod=lambda: hashlib.new('ripemd160'))

Cheers,
Chris

-- 
Follow the path of the Iguana...
http://rebertia.com
--
http://mail.python.org/mailman/listinfo/python-list

Re: New Python 3.0 string formatting - really necessary?

[Aaron Brady]

On Dec 21, 10:58 am, MRAB  wrote:
> Aaron Brady wrote:
> > On Dec 21, 10:31 am, MRAB  wrote:
snip
> >> The original format is a string. The result of '%' is a string if
> >> there's only 1 placeholder to fill, or a (partial) format object (class
> >> "Format"?) if there's more than one. Similarly, the format object
> >> supports '%'. The result of '%' is a string if there's only 1
> >> placeholder to fill, or a new (partial) format object if there's more
> >> than one.
>
> >>  >>> f = "%r %i"
> >>  >>> type(f)
> >> 
> >>  >>> f = f % (2, 3, 4)
> >>  >>> type(f)
> >> 
> >>  >>> f = f % 1
> >>  >>> type(f)
> >> 
>
> > Alright, so how are you handling:
>
>  f= "%s %i"
>  type( f )
> > 
>  f= f% '%i'  #now '%i %i'
>  type( f )
> > 
>  f= f% 1
>  type( f )
> > ?
>
> > In other words, are you slipping '1' in to the very first available
> > slot, or the next, after the location of the prior?
>
> Let's assume that Format objects display their value like the equivalent
> string format:
>
>  >>> f = "%r %i"
>  >>> f
> '%r %i'
>  >>> f = f % (2, 3, 4)
>  >>> f
> 
>  >>> f = f % 1
>  >>> f
> '(2, 3, 4) 1'
>  >>>
>  >>> f = "%s %i"
>  >>> f
> '%s %i'
>  >>> f = f % '%i'
>  >>> f
> 
>  >>> f = f % 1
>  >>> f
> '%%i 1'

I assume you meant '%i 1' since there are no more flags in f, and it's
returned to a regular string.

'f %= 1' doesn't work any more as in-place modulo, since one time, 'f'
is a Format object, the other, 'f' is a string.  Just raise an
exception for that (or assign to __class__ IINM if I'm not mistaken).

Actually, the class you showed is kind of nifty.  Tuples are correctly
interpolated.  I think on the whole you'll use more parenthesis, since
each term in the tuple appears separately, and might be an expression
(have a lower-precedence op.), as well as more modulo signs.

You can currently do-it-yourself, you just need a constructor in the
format string.

>>> f = Format("%r %i")
>>> type(f)

>>> f = f % (2, 3, 4)
>>> type(f)


Or, as someone suggested earlier, a new literal marking:

>>> f = f"%r %i"
>>> type(f)

--
http://mail.python.org/mailman/listinfo/python-list

Re: Are python objects thread-safe?

[Aaron Brady]

On Dec 21, 12:51 pm, RajNewbie  wrote:
> Say, I have two threads, updating the same dictionary object - but for
> different parameters:
> Please find an example below:
> a = {file1Data : '',
>        file2Data : ''}
>
> Now, I send it to two different threads, both of which are looping
> infinitely:
> In thread1:
> a['file1Data'] = open(filename1).read
>           and
> in thread2:
> a['file2Data'] = open(filename2).read
>
> My question is  - is this object threadsafe? - since we are working on
> two different parameters in the object. Or should I have to block the
> whole object?

Threads take turns with the Global Interpreter Lock, so a Python
thread is sure to have the GIL before it calls a method on some
object.  So yes, with the rare exception (that I don't want to not
mention) that if you've got non-Python threads running in your process
somehow, they don't make the guarantee of enforcing that.
--
http://mail.python.org/mailman/listinfo/python-list

Re: wxpython for python 3.0 ?

[Benjamin Kaplan]

On Sun, Dec 21, 2008 at 4:42 PM,  wrote:

> The wxpython web describes compatability with python 2.4 & 2.5 .
> Does it work with 3.0 ?   If not, anyone have a clue as to when ?


This question was asked a couple of times on the wxpython-users mailing
list. It's probably going to take a while. For now, I'd stick to python 2.x.
The next version of wxPython should support 2.6, so use that and try to make
your code relatively compatible with Python 3 (use the division,
print_function, and unicode_literals future imports). Then, you'll be all
set when Robin gets around to porting everything to Python 3.

>
> --
> http://mail.python.org/mailman/listinfo/python-list
>
--
http://mail.python.org/mailman/listinfo/python-list

Re: New Python 3.0 string formatting - really necessary?

[Benjamin Kaplan]

On Sun, Dec 21, 2008 at 2:26 PM, r  wrote:

> I noticed when i mentioned "self" nobody wants to touch that subject.
> There could be many reasons why...
>
> 0.) nobody but the 10 regulars i see here exists


if you only see 10 people, you must not be following this list very well.


>
> 1.) nobody cares(doubt it)


If people cared that much, they wouldn't use python.

>
> 2.) nobody is brave enough to question it(maybe)


Check the archives. There have been plenty of people who questioned it.
People got so bored with them that the only answer you're likely to get now
is people quoting the zen.

>
> 3.) most people like to type self over and over again(doubt it)


You have to type self over and over again? I don't know about the other
editors, about Eclipse/PyDev's autocomplete will add it to any function
declared within a class unless it has @staticmethod or @classmethod above
it.

>
> 4.) most people here have given up on changing the BDFL's mind about
> it. (good possibility)
> 5.) this is a hot-button topic(no doubt in my mind!)

Not really. Again, if you care that much about explicit self, use another
language.

>
>
> I think Guido's intension's are pure, but this is a major turnoff to
> new users. Do we really need to hold a new users hand that much. Does
> it really matter if they know the path of said obj. If you can't
> fiqure this out for yourself you have much greater problems.
>
> I do not like self, and i lamented it from day one, now it is second
> nature to me but does that mean it is really needed?? I feel i have
> been brainwashed into its usage.
>
> This was the reason for using indention over the bracket plague in
> python. REDUNDANCY!!! Why not dump self and make the language cleaner.
> I love python's classes, but HATE self.redundant! This really needs to
> be fixed, and you have not heard the last from me about it!!!
>
> 3000 would have been the perfect time to dump self and really clean up
> the language, and it's not too late, dawn is not upon us yet.


yes, it is too late. Python 3 is out and done. There will be no more
sweeping, backwards-incompatible changes until Python 4.


>
> --
> http://mail.python.org/mailman/listinfo/python-list
>
--
http://mail.python.org/mailman/listinfo/python-list

Re: [Help] The pywinauto Can't select the MDI's menu using the MenuItems() which return [].

[gagsl-py2]

--- El vie 19-dic-08, 为爱而生  escribió:

> I use the WORD Only for my example.
> The application I test is similar to the WORD and It
> has't the COM.

The code below opens the Choose Font dialog on my Spanish Windows version:

py> from pywinauto.application import Application
py> app = Application.start("Notepad.exe")
py> app[u"Sin título - Bloc de notas"].MenuSelect(u"Formato->Fuente")

(using an English version, the last line would be 
app.UntitledNotepad.MenuSelect("Format->Font") I presume)

There are many examples in the documentation, and some more info at 
http://pywinauto.seleniumhq.org/

I think there is a pywinauto users list.


> 2008/12/19 Gabriel Genellina 
> 
> > En Thu, 18 Dec 2008 11:28:54 -0200, Simon Brunning
> >  escribió:
> >
> >  2008/12/18 为爱而生 :
> >>
> >>> This problem also use the following
> discription:
> >>> How to use pywinauto to open WORD and select
> its Menu.
> >>> I can't do that and have no idea why!
> >>> Looking forward your help,Thanks!
> >>>
> >>
> >> Word can be automated with COM. My golden rule is
> that automation via
> >> GUI driving is always a last resort.

-- 
Gabriel Genellina


  

¡Buscá desde tu celular!

Yahoo! oneSEARCH ahora está en Claro

http://ar.mobile.yahoo.com/onesearch
--
http://mail.python.org/mailman/listinfo/python-list

Re: Are python objects thread-safe?

[James Mills]

On Mon, Dec 22, 2008 at 4:51 AM, RajNewbie  wrote:
> Say, I have two threads, updating the same dictionary object - but for
> different parameters:
> Please find an example below:
> a = {file1Data : '',
>   file2Data : ''}
>
> Now, I send it to two different threads, both of which are looping
> infinitely:
> In thread1:
> a['file1Data'] = open(filename1).read
>  and
> in thread2:
> a['file2Data'] = open(filename2).read
>
> My question is  - is this object threadsafe? - since we are working on
> two different parameters in the object. Or should I have to block the
> whole object?

I believe (iirc), all basic data types
and objects are thread-safe. I could
be wrong though - I don't tend to
use threads much myself :)

cheers
James
--
http://mail.python.org/mailman/listinfo/python-list

Re: Twisted for non-networking applications

[James Mills]

On Mon, Dec 22, 2008 at 4:27 AM, Kottiyath  wrote:
> Hi all,
>   Is it a good idea to use Twisted inside my application, even though
> it has no networking part in it?
>   Basically, my application needs lots of parallel processing - but I
> am rather averse to using threads - due to myraid issues it can cause.
> So, I was hoping to use a reactor pattern to avoid the threads. I am
> using twisted in another part of the application for networking, so I
> was hoping to use the same for the non-networking part for reusing the
> reactor pattern.
>   If somebody can help me on this, it would be very helpful.

Alternatively you could give circuits (1)
a go. It _can_ be a nice alternative to
Twisted and isn't necessarily focused on
Networking applications.

cheers
James

1. http://trac.softcircuit.com.au/circuits/
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[James Mills]

On Mon, Dec 22, 2008 at 4:47 AM, r  wrote:
> Could not have said it better myself Luis, i stay as far away from C
> as i can. But there are usage cases for it.

If you can think of 1 typical common case
I'll reward you with praise! :)

By the way, by common and typical I mean
use-cases that you'd typically find in every
day applications and user tools, software,
games, etc.

In case anyone is not aware, Python is
also used for heavy scientific computational
problems, games such as Civilisation and
others, and I believe (correct me if I"m wrong)
it's also used by NASA.

--JamesMills
--
http://mail.python.org/mailman/listinfo/python-list

Re: New Python 3.0 string formatting - really necessary?

[r]

Bruno,
I thought i had already gone up, up, and away to your kill filter.
hmm, guess you had a change of heart ;D
--
http://mail.python.org/mailman/listinfo/python-list

noob trouble with IDLE

[Ronald Rodriguez]

Hi, Im new to python and I've just started using Byte of Python, running the
samples etc. Im using IDLE on Xp. Ok, here's the thing.
A sample script makes a call to the os.system() function in order to zip
some files. Everything works fine when running from the command line, but
the same code fails when I try Run --> Run module on IDLE. Im using 7z to
zip the files. Again, everything is OK when running from the command line.
Remember, Im new to python and programming. I've done some google search
without results. Maybe its just too simple :-(  . Any help would be
appreciated. Thanks in advance.
--
http://mail.python.org/mailman/listinfo/python-list

wxpython for python 3.0 ?

[dlemper]

The wxpython web describes compatability with python 2.4 & 2.5 .
Does it work with 3.0 ?   If not, anyone have a clue as to when ?
--
http://mail.python.org/mailman/listinfo/python-list

Re: New Python 3.0 string formatting - really necessary?

[r]

Hey Bruno,
Thanks for spelling it out for me :D
--
http://mail.python.org/mailman/listinfo/python-list

Re: Are Django/Turbogears too specific?

[Philip Semanchuk]

On Dec 21, 2008, at 3:14 PM, Bruno Desthuilliers wrote:


Philip Semanchuk a écrit :
(snip)
From the reading I did, I gathered that Django was really good if  
you want to do what Django is good at, but not as easy to customize  
as, say, Pylons.


That was my first impression too, and was more or less true some  
years ago. After more experience, having gained a deeper knowledge  
of Django's internals, I can tell you this is just not true. You can  
"customize" it as you want - meaning: you can use any ORM (or no ORM  
at all) and any template language you want, as long as you don't  
intend to use django's ORM and template language related features  
(which just don't exist in Pylons). IOW : Django is just as flexible  
as Pylons (or pretty close to), but has more to offer if you stick  
to builtin components.


Based on what I read, I got the idea that Django *can* be as flexible  
as Pylons, but most people find it *easier* to take advantage of  
Pylons' flexibility. In other words, no one is saying Django is  
incapable, but that it is less focused on making it easy to allow  
developers to mix & match components and more focused on providing a  
smooth tool with which to work.


NB : not to dismiss Pylons, which is a pretty great framework too,  
and use IMHO better default components (namely SQLAlchemy and Mako).


I prefer Mako over the other template languages I've seen.





--
http://mail.python.org/mailman/listinfo/python-list

Re: Are Django/Turbogears too specific?

[Bruno Desthuilliers]

Philip Semanchuk a écrit :
(snip)
 From the reading I did, I gathered that Django was really good if you 
want to do what Django is good at, but not as easy to customize as, say, 
Pylons.


That was my first impression too, and was more or less true some years 
ago. After more experience, having gained a deeper knowledge of Django's 
internals, I can tell you this is just not true. You can "customize" it 
as you want - meaning: you can use any ORM (or no ORM at all) and any 
template language you want, as long as you don't intend to use django's 
ORM and template language related features (which just don't exist in 
Pylons). IOW : Django is just as flexible as Pylons (or pretty close 
to), but has more to offer if you stick to builtin components.


NB : not to dismiss Pylons, which is a pretty great framework too, and 
use IMHO better default components (namely SQLAlchemy and Mako).


--
http://mail.python.org/mailman/listinfo/python-list

Re: Are Django/Turbogears too specific?

[Bruno Desthuilliers]

Gilles Ganault a écrit :

Hi

I'd like to rewrite a Web 2.0 PHP application in Python with AJAX, and
it seems like Django and Turbogears are the frameworks that have the
most momentum.

I'd like to use this opportunity to lower the load on servers, as the
PHP application wasn't built to fit the number of users hammering the
servers now.

I'm concerned, though, that these frameworks they may be too specific
to the tasks they were originally developped for (news articles,
AFAIK). Do you think I should just use eg. CherryPy and some basic
AJAX?


I can't tell about Turbogears, but you're dead wrong if you think that 
there's anything specific to "news articles" in Django. It's *not* a 
CMS, it's a web programming framework, and is totally agnostic about 
what kind of application you're using it for.


--
http://mail.python.org/mailman/listinfo/python-list

Re: trapping all method calls in a class...

[MrJean1]

The decorate_meths() function as given fails:

  TypeError: 'dictproxy' object does not support item assignment

But this version avoids that error (on Python 2.2 thru 2.6):

def decorate_meths(klass):
for nam, val in klass.__dict__.items():
if callable(val):
setattr(klass, nam, decorate(val))
return klass  # ?


/Jean Brouwers


On Dec 20, 11:32 pm, "Chris Rebert"  wrote:
> On Sat, Dec 20, 2008 at 11:12 PM, Piyush Anonymous
>
>  wrote:
> > hi,
> > i need to trap all method calls in a class in order to update a counter
> > which is increased whenever a method is called and decreased whenever method
> > returns. in order to that i am trying to write a decorator for all the
> > methods.
>
> > see the code here with error.
> > ---
> >http://codepad.org/2w7JVvDB
> > 
> > any suggestions? any other better way of doing it?
>
> I call unnecessary use of metaclasses! Here's my (untested) attempt at
> a simpler class decorator approach:
>
> def decorate_meths(klass):
>     attrs = klass.__dict__.items()
>         for name, val in attrs:
>                 if callable(val):
>                         klass.__dict__[name] = decorate(val)
>
> def decorate(method):
>     #should be called for every method call in the class
>     def decorated(self, *args, **kwds):
>         print "2 Inside __call__()"
>         returnval = method(self, *args,**kwds)
>         print "3 After self.f(*args)"
>         return returnval
>     return decorated
>
> #...@decorate_meths <-- this syntax requires a later Python version
> class Person(object):
>         def testprint(self,val):
>                 print "blah blah"
> Person = decorate_meths(Person)
>
> #rest of code after the class definition would be the same
>
> Sidenotes about your code:
> - `args` and `kwds` are the conventional names for the * and **
> special arguments
> - the `methodname` variable was actually getting method objects, not
> strings, as its values; this was probably part of the bug in your
> program
>
> Cheers,
> Chris
>
> --
> Follow the path of the Iguana...http://rebertia.com

--
http://mail.python.org/mailman/listinfo/python-list

Re: New Python 3.0 string formatting - really necessary?

[Bruno Desthuilliers]

r a écrit :

I noticed when i mentioned "self" nobody wants to touch that subject.
There could be many reasons why...

0.) nobody but the 10 regulars i see here exists
1.) nobody cares(doubt it)
2.) nobody is brave enough to question it(maybe)
3.) most people like to type self over and over again(doubt it)
4.) most people here have given up on changing the BDFL's mind about
it. (good possibility)
5.) this is a hot-button topic(no doubt in my mind!)


6.) you are definitevely clueless.

(snip)


I love python's classes, but HATE self.redundant!


This declaration only makes clear that answer to your above question is #6.


This really needs to
be fixed,


Your ignorance needs to be fixed, yes, indeed. Please go and fix it - 
all the relevant materials is available in (or linked from somewhere in) 
this newgroup's archives.



and you have not heard the last from me about it!!!


As far as I'm concerned, yes. Welcome to my bozo filter. Please come 
back when you'll have grown a brain.

--
http://mail.python.org/mailman/listinfo/python-list

Re: New Python 3.0 string formatting - really necessary?

[Bruno Desthuilliers]

walterbyrd a écrit :

On Dec 20, 5:05 pm, Roy Smith 


He got really hung up on the % syntax.


I guess it's good to know that there is, at least, one person in the
world doesn't like the % formatting. As least the move was not
entirely pointless.

But, you must admit, of all the things people complain about with
Python, the % formatting is probably one of the least common
complaints. Complaints about Python's speed seem much more common.



People complaining about the perceived issues wrt/ Python's speed are 
welcome to fix it. As far as I'm concerned, I find the perfs more than 
acceptable when you take Python's dynamism into account. Strange enough, 
no one seems to complain about PHP or Ruby's performances...




Yet, 3.0 makes the speed worse,


first make it right, then make it fast...


and "fixes" a non-problem.

I can see where the new formatting might be helpful in some cases.
But, I am not sure it's worth the cost.


Err... _Which_ cost exactly ?
--
http://mail.python.org/mailman/listinfo/python-list

Re: New Python 3.0 string formatting - really necessary?

[Bruno Desthuilliers]

r a écrit :
(snip clueless rant)

One more big complaint "THE BACKSLASH PLAGUE". ever tried regexp?


Yes.

exp = re.compile(r"no \problem \with \backslashes")


, or
file paths?. 


You mean _dos/windows_ file path separator ? It was indeed a stupid 
choice _from microsoft_ to choose the by then well established escape 
char (the backslash) as a file path separator. But hopefully, Python 
handles it gracefully: you can either use raw strings (which I stronly 
advise you learn about instead of whining) or just the traditional unix 
one (forward slash) instead.



All because that little backslash char is a line
continuation character,


Totally clueless, as usual... Why don't you just READ THAT FUCKING MANUAL ?

--
http://mail.python.org/mailman/listinfo/python-list

Re: Are Django/Turbogears too specific?

[Philip Semanchuk]

On Dec 21, 2008, at 2:41 PM, Gilles Ganault wrote:


Hi

I'd like to rewrite a Web 2.0 PHP application in Python with AJAX, and
it seems like Django and Turbogears are the frameworks that have the
most momentum.


I don't have any practical experience with these, but I've done some  
research. My impression is that Pylons has more momentum than TG. The  
latter project has declared the 1.x branch to be a dead end, and  
they're working on a 2.0 branch that's not out yet. I could be wrong,  
but that's what I gathered from my reading.



I'm concerned, though, that these frameworks they may be too specific
to the tasks they were originally developped for (news articles,
AFAIK).


From the reading I did, I gathered that Django was really good if you  
want to do what Django is good at, but not as easy to customize as,  
say, Pylons. Pylons, on the other hand, is a little more complicated  
because it's made of several different parts, but the positive side of  
"complicated" is "flexible".



Do you think I should just use eg. CherryPy and some basic AJAX?


Yes or no, depending on what you're trying to do! =)

Good luck
Philip

--
http://mail.python.org/mailman/listinfo/python-list

Re: Are Django/Turbogears too specific?

[Patrick Mullen]

On Sun, Dec 21, 2008 at 11:41 AM, Gilles Ganault  wrote:
> Hi
>
> I'd like to rewrite a Web 2.0 PHP application in Python with AJAX, and
> it seems like Django and Turbogears are the frameworks that have the
> most momentum.
>
> I'd like to use this opportunity to lower the load on servers, as the
> PHP application wasn't built to fit the number of users hammering the
> servers now.
>
> I'm concerned, though, that these frameworks they may be too specific
> to the tasks they were originally developped for (news articles,
> AFAIK). Do you think I should just use eg. CherryPy and some basic
> AJAX?
>
> Thank you for any feedback.
> --
> http://mail.python.org/mailman/listinfo/python-list
>

No, they aren't very specific at all.  Both frameworks allow
configuration at nearly every level.
The cool, slick admin interface might not be so useful depending on your
application, but everything else has uses in just about any field.  I only have
experience with TG and cherrypy, TG for me is almost like cherrypy
(I'm not sure if it still does,
I've been out of the loop, but it used to use cherrypy under the
hood), but a bit
nicer to work with, especially if you have any AJAX.
--
http://mail.python.org/mailman/listinfo/python-list

Re: New Python 3.0 string formatting - really necessary?

[Patrick Mullen]

On Sun, Dec 21, 2008 at 11:26 AM, r  wrote:
> I noticed when i mentioned "self" nobody wants to touch that subject.
> There could be many reasons why...
>
> 0.) nobody but the 10 regulars i see here exists
> 1.) nobody cares(doubt it)
> 2.) nobody is brave enough to question it(maybe)
> 3.) most people like to type self over and over again(doubt it)
> 4.) most people here have given up on changing the BDFL's mind about
> it. (good possibility)
> 5.) this is a hot-button topic(no doubt in my mind!)

It's a combination between (4) (5) and (6).  6 being, we have
discussed "self" every week for the past 6 years, it hasn't changed
yet, it's not going away, it's not a trivial "problem", deal with it.

(0) is ridiculous, there are more than 10 respondents to this post alone.
(1) - if nobody cared it wouldn't come up every week, but it's been
discussed so much most are tired of it
(2) - people question it all the time, usually people who are new to
the language but not always.  The discussion generally doesn't amount
to anything
(3) - It's not about wanting to type self over and over again, it's
about being able to start with functions or start with classes, and
easily refactor to the other way when needed; and never having a
chance to wonder where a variable came from.  There are ups and downs
to self, it is generally more work to remove it than it is worth, what
would the gain be?  We'd be trading some ups and downs for some other
ups and downs.  And no, BDFL is not going to bend on self.  He almost
bent on the issue a few weeks ago, but his proposition merely changed
some syntax - self was still there.

On Sun, Dec 21, 2008 at 11:01 AM, Christian Heimes  wrote:
> We could have waited a few more months or even a few more years with a
> 3.0 release. There is always - I repeat ALWAYS - work to do. For an open
> source project like Python "release early, release often" works better.

Good point, and I agree.  It's too early for people to complain about
python 3 being
slow.  It's also too both too late and too early to complain about
things in python 3
that are thought of as a step backward.  It's too late, because python
3 is out and
it's already been changed!  Things are not going to change back.  Complaints are
a bit useless at this point, except to let off steam.  It's too early,
because without
using python3 in a major project, from the ground up, with the new features,
the benefits or negatives for all of the changes cannot truly be known.
--
http://mail.python.org/mailman/listinfo/python-list

Re: New Python 3.0 string formatting - really necessary?

[MRAB]

r wrote:

I noticed when i mentioned "self" nobody wants to touch that subject.
There could be many reasons why...

0.) nobody but the 10 regulars i see here exists
1.) nobody cares(doubt it)
2.) nobody is brave enough to question it(maybe)
3.) most people like to type self over and over again(doubt it)
4.) most people here have given up on changing the BDFL's mind about
it. (good possibility)
5.) this is a hot-button topic(no doubt in my mind!)


6.) nobody here wants to go through that whole discussion yet again

--
http://mail.python.org/mailman/listinfo/python-list

Re: New Python 3.0 string formatting - really necessary?

[Luis Zarrabeitia]

Quoting r :

> I noticed when i mentioned "self" nobody wants to touch that subject.
> There could be many reasons why...
> 
> 0.) nobody but the 10 regulars i see here exists
> 1.) nobody cares(doubt it)
> 2.) nobody is brave enough to question it(maybe)
> 3.) most people like to type self over and over again(doubt it)
> 4.) most people here have given up on changing the BDFL's mind about
> it. (good possibility)
> 5.) this is a hot-button topic(no doubt in my mind!)

You forgot
6.) it is the best, cleanest, most consistent and extensible way to do it.
 
> This was the reason for using indention over the bracket plague in
> python. REDUNDANCY!!! Why not dump self and make the language cleaner.
> I love python's classes, but HATE self.redundant! This really needs to
> be fixed, and you have not heard the last from me about it!!!

Do you also hate cls.redundant on a classmethod? Would you rather type 'self'
even when it is referring to a class? Would you like to resort to a hack, like
C#3.0's 'this' explicit argument, when monkey-patching?

I used to hate 'self'. Then I met classmethods, metaclasses and decorators, and
the 'new'/'types' modules. It's just one of those examples where Guido's time
machine works flawlessly.

> 3000 would have been the perfect time to dump self and really clean up
> the language, and it's not too late, dawn is not upon us yet.

No need to wait for python 3000.

You can have a 'selfless metaclass' right now:

http://www.voidspace.org.uk/python/articles/metaclasses.shtml

(BTW, I really hope you are complaining about the explicit self on the argument
list, and not about the 'self.' prefix - if that were the case, what magic would
you propose for the compiler to guess when you are referring to locals, globals,
class or instance variables?)


-- 
Luis Zarrabeitia
Facultad de Matemática y Computación, UH
http://profesores.matcom.uh.cu/~kyrie


--
http://mail.python.org/mailman/listinfo/python-list

Re: Removing self.

[skip]

r> I do not like self, and i lamented it from day one, now it is second
r> nature to me but does that mean it is really needed?? I feel i have
r> been brainwashed into its usage.

...

r> 3000 would have been the perfect time to dump self and really clean up
r> the language, and it's not too late, dawn is not upon us yet.

Bruce Eckel proposes removing self from argument lists:

http://www.artima.com/weblogs/viewpost.jsp?thread=239003

Guido responds:

http://neopythonic.blogspot.com/2008/10/why-explicit-self-has-to-stay.html

-- 
Skip Montanaro - s...@pobox.com - http://smontanaro.dyndns.org/
--
http://mail.python.org/mailman/listinfo/python-list

Are Django/Turbogears too specific?

[Gilles Ganault]

Hi

I'd like to rewrite a Web 2.0 PHP application in Python with AJAX, and
it seems like Django and Turbogears are the frameworks that have the
most momentum.

I'd like to use this opportunity to lower the load on servers, as the
PHP application wasn't built to fit the number of users hammering the
servers now.

I'm concerned, though, that these frameworks they may be too specific
to the tasks they were originally developped for (news articles,
AFAIK). Do you think I should just use eg. CherryPy and some basic
AJAX?

Thank you for any feedback.
--
http://mail.python.org/mailman/listinfo/python-list

Re: New Python 3.0 string formatting - really necessary?

[r]

I noticed when i mentioned "self" nobody wants to touch that subject.
There could be many reasons why...

0.) nobody but the 10 regulars i see here exists
1.) nobody cares(doubt it)
2.) nobody is brave enough to question it(maybe)
3.) most people like to type self over and over again(doubt it)
4.) most people here have given up on changing the BDFL's mind about
it. (good possibility)
5.) this is a hot-button topic(no doubt in my mind!)

I think Guido's intension's are pure, but this is a major turnoff to
new users. Do we really need to hold a new users hand that much. Does
it really matter if they know the path of said obj. If you can't
fiqure this out for yourself you have much greater problems.

I do not like self, and i lamented it from day one, now it is second
nature to me but does that mean it is really needed?? I feel i have
been brainwashed into its usage.

This was the reason for using indention over the bracket plague in
python. REDUNDANCY!!! Why not dump self and make the language cleaner.
I love python's classes, but HATE self.redundant! This really needs to
be fixed, and you have not heard the last from me about it!!!

3000 would have been the perfect time to dump self and really clean up
the language, and it's not too late, dawn is not upon us yet.
--
http://mail.python.org/mailman/listinfo/python-list

Re: New Python 3.0 string formatting - really necessary?

[Christian Heimes]

Patrick Mullen schrieb:
> 2) In my experience, major version changes tend to be slower than
> before.  When a lot of things change, especially if very low-level
> things change, as happened in python 3.0, the new code has not yet
> went through many years of revision and optimization that the old code
> has.  In my opinion, python 3 was rushed out the door a bit.  It could
> have done with a few more months of optimization and polishing.
> However, on the other hand, it is going to take so long for python
> infrastructure to convert to python 3, that an earlier release makes
> sense, even if it hasn't been excessively polished.  The biggest
> reason for the speed change is the rewritten stdio and
> unicode-everything.  Hopefully this stuff can be improved in future
> updates.  I don't think anyone WANTS cpython to be slower.

The 3.0 release targets third party developers. Authors of 3rd party
extensions and libraries need a stable API to port their software to a
new major release. The main objective was feature completeness and
stability. If you need speed either stick to the 2.x series or wait
until 3.1 is out.

We could have waited a few more months or even a few more years with a
3.0 release. There is always - I repeat ALWAYS - work to do. For an open
source project like Python "release early, release often" works better.

Christian

--
http://mail.python.org/mailman/listinfo/python-list

Are python objects thread-safe?

[RajNewbie]

Say, I have two threads, updating the same dictionary object - but for
different parameters:
Please find an example below:
a = {file1Data : '',
   file2Data : ''}

Now, I send it to two different threads, both of which are looping
infinitely:
In thread1:
a['file1Data'] = open(filename1).read
  and
in thread2:
a['file2Data'] = open(filename2).read

My question is  - is this object threadsafe? - since we are working on
two different parameters in the object. Or should I have to block the
whole object?



--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[r]

Could not have said it better myself Luis, i stay as far away from C
as i can. But there are usage cases for it.
--
http://mail.python.org/mailman/listinfo/python-list

Twisted for non-networking applications

[Kottiyath]

Hi all,
   Is it a good idea to use Twisted inside my application, even though
it has no networking part in it?
   Basically, my application needs lots of parallel processing - but I
am rather averse to using threads - due to myraid issues it can cause.
So, I was hoping to use a reactor pattern to avoid the threads. I am
using twisted in another part of the application for networking, so I
was hoping to use the same for the non-networking part for reusing the
reactor pattern.
   If somebody can help me on this, it would be very helpful.
Regards
K
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[Luis M . González]

On Dec 21, 2:34 pm, r  wrote:
> RTFM, use as much python code and optimize with C where needed,
> problem solved!

That's true if your *really* need C's extra speed.
Most of the times, a better algorithm or psyco (or shedskin) can help
without having to use any other language.
This is unless you are hacking a kernel, writing device drivers or 3D
image processing.
For anything else, python is fast enough if you know how to optimize
your code.

Luis
--
http://mail.python.org/mailman/listinfo/python-list

Re: New Python 3.0 string formatting - really necessary?

[bearophileHUGS]

MRAB:
> Interesting. The re module uses a form of bytecode. Not sure about the
> relative cost of the dispatch code, though.

I was talking about the main CPython VM, but the same ideas may be
adapted for the RE engine too.

Bye,
bearophile
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[r]

RTFM, use as much python code and optimize with C where needed,
problem solved!
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[Krishnakant]

With my current experience with java, python and perl, I can only
suggest one thing to who ever feels that python or any language is slow.
By the way there is only one language with is fastest and that is
assembly.
And with regards to python, I am writing pritty heavy duty applications
right now.
Just to mention I am totally blind and I use a screen reader called orca
on the gnome desktop.  I hope readers here can understand that a screen
reader has to do a lot of real-time information processing and respond
with lightenning speed.
And Orca the scree reader is coded totally in python.
So that is one example.
So conclusion is is how you enhance your program by utilising the best
aspects of python.
happy hacking.
Krishnakant.
On Sun, 2008-12-21 at 16:33 +, MRAB wrote:
> Marc 'BlackJack' Rintsch wrote:
> > On Sat, 20 Dec 2008 14:18:40 -0800, cm_gui wrote:
> > 
> >>> Seriously cm_gui, you're a fool.
> >>> Python is not slow.
> >> haha, getting hostile?
> >> python fans sure are a nasty crowd.
> >>
> >> Python is SLOW.
> >>
> >> when i have the time, i will elaborate on this.
> > 
> > You are not fast enough to elaborate on Python's slowness!?  :-)
> > 
> > cm_gui is slow!
> > 
> > Ciao,
> > Marc 'BlackJack' Rintsch
> > 
> Correction:
> 
> cm_gui is SLOW! :-)
> --
> http://mail.python.org/mailman/listinfo/python-list

--
http://mail.python.org/mailman/listinfo/python-list

Re: New Python 3.0 string formatting - really necessary?

[MRAB]

Aaron Brady wrote:

On Dec 21, 10:31 am, MRAB  wrote:

Aaron Brady wrote:

On Dec 20, 8:49 pm, MRAB  wrote:

Aaron Brady wrote:

On Dec 20, 7:38 pm, Steven D'Aprano  wrote:

Instead of just whinging, how about making a suggestion to fix it? Go on,
sit down for an hour or ten and try to work out how a BINARY OPERATOR
like % (that means it can only take TWO arguments) can deal with an
arbitrary number of arguments, *without* having any special cases.
Go on. Take your time. I'll be waiting.

Hi, not to take sides, but, there is a possibility.
This behavior is currently legal:

"%i %%i" % 0 % 1

'0 1'
So, just extend it.  (Unproduced.)

"%i %i" % 0 % 1

'0 1'

"%r %i" % (2, 3, 4) % 1

'(2, 3, 4) 1'

"%r %i" % (2, 3, 4)

'(2, 3, 4) %i'
Which is quite clever and way ahead of its (posessive) time.

A couple of problems:
1. How do you handle a literal '%'? If you just double up then you'll
need to fix the string after all your substitutions.
2. What if a substitution introduces a '%'?
I suppose a possible solution would be to introduce a special format
string, including a literal, eg:
 f"%r %i" % (2, 3, 4) % 1
and then convert the result to a true string:
 print(str(f"%r %i" % (2, 3, 4) % 1))
(although print() would call __str__ anyway).
The format string would track where the last substitution occurred.
Hmm... I think I'll just learn the new method. :-)

Now that I'm fighting 'r's war for him/her...
Um, here's one possibility.  On the first interpolation, flags are
noted and stored apart from subsequent interpolations.  Then, use a
sentinel to terminate the interpolation.  (Unproduced.)

"%r %i" % ( 2, 3 ) % 0

'(2, 3) 0'

"%% %r" % ( 2, 3 ) % str.interp_end

'% (2, 3)'

"%sss%i" % "%d" % 0

'%dss0'
The first %s is replaced with %d, but doesn't hijack the '0'.  If you
want to interpolate the %d, use the sentinel.  The sentinel is what
causes '%%' to be handled.

"%sss%i" % "%d" % 0 % 1

Traceback (most recent call last):
  File "", line 1, in 
TypeError: not all arguments converted during string formatting

"%sss%i" % "%d" % 0 % str.interp_end % 1

'1ss0'
Treating tuples as a special case appears to be the simpler solution,
but this, 'chaining', to adopt the term, is still feasible.

A possible solution occurred to me shortly after I posted, but I decided
that sleep was more important. :-)

The original format is a string. The result of '%' is a string if
there's only 1 placeholder to fill, or a (partial) format object (class
"Format"?) if there's more than one. Similarly, the format object
supports '%'. The result of '%' is a string if there's only 1
placeholder to fill, or a new (partial) format object if there's more
than one.

 >>> f = "%r %i"
 >>> type(f)

 >>> f = f % (2, 3, 4)
 >>> type(f)

 >>> f = f % 1
 >>> type(f)



Alright, so how are you handling:


f= "%s %i"
type( f )



f= f% '%i'  #now '%i %i'
type( f )



f= f% 1
type( f )

?

In other words, are you slipping '1' in to the very first available
slot, or the next, after the location of the prior?

Let's assume that Format objects display their value like the equivalent 
string format:


>>> f = "%r %i"
>>> f
'%r %i'
>>> f = f % (2, 3, 4)
>>> f

>>> f = f % 1
>>> f
'(2, 3, 4) 1'
>>>
>>> f = "%s %i"
>>> f
'%s %i'
>>> f = f % '%i'
>>> f

>>> f = f % 1
>>> f
'%%i 1'

--
http://mail.python.org/mailman/listinfo/python-list

Re: New Python 3.0 string formatting - really necessary?

[Aaron Brady]

On Dec 21, 10:31 am, MRAB  wrote:
> Aaron Brady wrote:
> > On Dec 20, 8:49 pm, MRAB  wrote:
> >> Aaron Brady wrote:
> >>> On Dec 20, 7:38 pm, Steven D'Aprano  >>> cybersource.com.au> wrote:
>  Instead of just whinging, how about making a suggestion to fix it? Go on,
>  sit down for an hour or ten and try to work out how a BINARY OPERATOR
>  like % (that means it can only take TWO arguments) can deal with an
>  arbitrary number of arguments, *without* having any special cases.
>  Go on. Take your time. I'll be waiting.
> >>> Hi, not to take sides, but, there is a possibility.
> >>> This behavior is currently legal:
> >> "%i %%i" % 0 % 1
> >>> '0 1'
> >>> So, just extend it.  (Unproduced.)
> >> "%i %i" % 0 % 1
> >>> '0 1'
> >> "%r %i" % (2, 3, 4) % 1
> >>> '(2, 3, 4) 1'
> >> "%r %i" % (2, 3, 4)
> >>> '(2, 3, 4) %i'
> >>> Which is quite clever and way ahead of its (posessive) time.
> >> A couple of problems:
>
> >> 1. How do you handle a literal '%'? If you just double up then you'll
> >> need to fix the string after all your substitutions.
>
> >> 2. What if a substitution introduces a '%'?
>
> >> I suppose a possible solution would be to introduce a special format
> >> string, including a literal, eg:
>
> >>      f"%r %i" % (2, 3, 4) % 1
>
> >> and then convert the result to a true string:
>
> >>      print(str(f"%r %i" % (2, 3, 4) % 1))
>
> >> (although print() would call __str__ anyway).
>
> >> The format string would track where the last substitution occurred.
>
> >> Hmm... I think I'll just learn the new method. :-)
>
> > Now that I'm fighting 'r's war for him/her...
>
> > Um, here's one possibility.  On the first interpolation, flags are
> > noted and stored apart from subsequent interpolations.  Then, use a
> > sentinel to terminate the interpolation.  (Unproduced.)
>
>  "%r %i" % ( 2, 3 ) % 0
> > '(2, 3) 0'
>  "%% %r" % ( 2, 3 ) % str.interp_end
> > '% (2, 3)'
>  "%sss%i" % "%d" % 0
> > '%dss0'
>
> > The first %s is replaced with %d, but doesn't hijack the '0'.  If you
> > want to interpolate the %d, use the sentinel.  The sentinel is what
> > causes '%%' to be handled.
>
>  "%sss%i" % "%d" % 0 % 1
> > Traceback (most recent call last):
> >   File "", line 1, in 
> > TypeError: not all arguments converted during string formatting
>  "%sss%i" % "%d" % 0 % str.interp_end % 1
> > '1ss0'
>
> > Treating tuples as a special case appears to be the simpler solution,
> > but this, 'chaining', to adopt the term, is still feasible.
>
> A possible solution occurred to me shortly after I posted, but I decided
> that sleep was more important. :-)
>
> The original format is a string. The result of '%' is a string if
> there's only 1 placeholder to fill, or a (partial) format object (class
> "Format"?) if there's more than one. Similarly, the format object
> supports '%'. The result of '%' is a string if there's only 1
> placeholder to fill, or a new (partial) format object if there's more
> than one.
>
>  >>> f = "%r %i"
>  >>> type(f)
> 
>  >>> f = f % (2, 3, 4)
>  >>> type(f)
> 
>  >>> f = f % 1
>  >>> type(f)
> 

Alright, so how are you handling:

>>> f= "%s %i"
>>> type( f )

>>> f= f% '%i'  #now '%i %i'
>>> type( f )

>>> f= f% 1
>>> type( f )
?

In other words, are you slipping '1' in to the very first available
slot, or the next, after the location of the prior?
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[MRAB]

Marc 'BlackJack' Rintsch wrote:

On Sat, 20 Dec 2008 14:18:40 -0800, cm_gui wrote:


Seriously cm_gui, you're a fool.
Python is not slow.

haha, getting hostile?
python fans sure are a nasty crowd.

Python is SLOW.

when i have the time, i will elaborate on this.


You are not fast enough to elaborate on Python's slowness!?  :-)

cm_gui is slow!

Ciao,
Marc 'BlackJack' Rintsch


Correction:

cm_gui is SLOW! :-)
--
http://mail.python.org/mailman/listinfo/python-list

Re: New Python 3.0 string formatting - really necessary?

[MRAB]

Aaron Brady wrote:

On Dec 20, 8:49 pm, MRAB  wrote:

Aaron Brady wrote:

On Dec 20, 7:38 pm, Steven D'Aprano  wrote:

Instead of just whinging, how about making a suggestion to fix it? Go on,
sit down for an hour or ten and try to work out how a BINARY OPERATOR
like % (that means it can only take TWO arguments) can deal with an
arbitrary number of arguments, *without* having any special cases.
Go on. Take your time. I'll be waiting.

Hi, not to take sides, but, there is a possibility.
This behavior is currently legal:

"%i %%i" % 0 % 1

'0 1'
So, just extend it.  (Unproduced.)

"%i %i" % 0 % 1

'0 1'

"%r %i" % (2, 3, 4) % 1

'(2, 3, 4) 1'

"%r %i" % (2, 3, 4)

'(2, 3, 4) %i'
Which is quite clever and way ahead of its (posessive) time.

A couple of problems:

1. How do you handle a literal '%'? If you just double up then you'll
need to fix the string after all your substitutions.

2. What if a substitution introduces a '%'?

I suppose a possible solution would be to introduce a special format
string, including a literal, eg:

 f"%r %i" % (2, 3, 4) % 1

and then convert the result to a true string:

 print(str(f"%r %i" % (2, 3, 4) % 1))

(although print() would call __str__ anyway).

The format string would track where the last substitution occurred.

Hmm... I think I'll just learn the new method. :-)


Now that I'm fighting 'r's war for him/her...

Um, here's one possibility.  On the first interpolation, flags are
noted and stored apart from subsequent interpolations.  Then, use a
sentinel to terminate the interpolation.  (Unproduced.)


"%r %i" % ( 2, 3 ) % 0

'(2, 3) 0'

"%% %r" % ( 2, 3 ) % str.interp_end

'% (2, 3)'

"%sss%i" % "%d" % 0

'%dss0'

The first %s is replaced with %d, but doesn't hijack the '0'.  If you
want to interpolate the %d, use the sentinel.  The sentinel is what
causes '%%' to be handled.


"%sss%i" % "%d" % 0 % 1

Traceback (most recent call last):
  File "", line 1, in 
TypeError: not all arguments converted during string formatting

"%sss%i" % "%d" % 0 % str.interp_end % 1

'1ss0'

Treating tuples as a special case appears to be the simpler solution,
but this, 'chaining', to adopt the term, is still feasible.

A possible solution occurred to me shortly after I posted, but I decided 
that sleep was more important. :-)


The original format is a string. The result of '%' is a string if 
there's only 1 placeholder to fill, or a (partial) format object (class 
"Format"?) if there's more than one. Similarly, the format object 
supports '%'. The result of '%' is a string if there's only 1 
placeholder to fill, or a new (partial) format object if there's more 
than one.


>>> f = "%r %i"
>>> type(f)

>>> f = f % (2, 3, 4)
>>> type(f)

>>> f = f % 1
>>> type(f)

--
http://mail.python.org/mailman/listinfo/python-list

Re: New Python 3.0 string formatting - really necessary?

[Marc 'BlackJack' Rintsch]

On Sun, 21 Dec 2008 15:30:34 +, Duncan Booth wrote:

> Marc 'BlackJack' Rintsch  wrote:
> 
>>> a+b+c+d might execute a.__add__(b,c,d) allowing more efficient string
>>> concatenations or matrix operations, and a%b%c%d might execute as
>>> a.__mod__(b,c,d).
>> 
>> But that needs special casing strings and ``%`` in the comiler, because
>> it might not be always safe to do this on arbitrary objects.  Only in
>> cases where the type of `a` is known at compile time and ``a % b``
>> returns an object of ``type(a)``.
>> 
> I could be wrong, but I don't see that would be the case.
> 
> I think it would be safe (in this hypothetical universe) any time that
> 'a' had a method __mod__ which accepted more than one argument.

And returns an object of ``type(a)`` or at least a "duck type" so that it 
is guaranteed that ``a.__mod__(b, c)`` really has the same semantics as 
``a.__mod__(b).__mod__(c)``.  For arbitrary objects `a`, `b`, and `c` 
that are not known at compile time, how could the compiler decide if it 
is safe to emit code that calls `a.__mod__()` with multiple arguments?

Ciao,
Marc 'BlackJack' Rintsch
--
http://mail.python.org/mailman/listinfo/python-list

Re: New Python 3.0 string formatting - really necessary?

[Mel]

Duncan Booth wrote:

> I don't see that. What I suggested was that a % b % c would map to
> a.__mod__(b,c). (a % b) % c would also map to that, but a % (b % c) could
> only possibly map to a.__mod__(b.__mod__(c))

There's a compiling problem here, no?  You don't want a%b%c to implement as
a.__mod__(b,c) if a is a number.

Mel.

--
http://mail.python.org/mailman/listinfo/python-list

Re: New Python 3.0 string formatting - really necessary?

[Aaron Brady]

On Dec 21, 8:50 am, Steve Holden  wrote:
> r wrote:
snip
> > This all really comes down to the new python users. Yea, i said it.
> > Not rabid fanboys like Steven and myself.(i can't speak for walter but
> > i think he would agree) Are we going to make sure joe-blow python
> > newbie likes the language. And doesn't get turned off and run over to
> > ruby or whoever. Like it or not, without newusers python is doomed to
> > the same fate as all the other "great" languages who had their 15 mins
> > of fame.
>
> > We must proactively seek out the wants of these new users and make
> > sure python stays alive. But we also must not sell are pythonic souls
>
>                          that's "our" (possessive), r, not "are" (verb)
>
> > in the process.
>
> > It would be nice to get a vote together and see what does the average
> > pythoneer want? What do they like, What do they dislike. What is the
> > state of the Python Union? Does anybody know, Does anybody care? I
> > think python is slipping away from it's dominate foothold on the
> > world. Google's use of python may be the only thing holding this house
> > of cards together. Ruby's "hype" is defiantly growing and unless we
> > strive for greatness, python may fail. I think ruby may have their act
> > together a little better than us right now. And since Ruby is such a
> > hodge-podge of different languages, the __init__ hold is there for
> > many.
>
> > what does joe-python want???
>
> Don't make the mistake of assuming there is a "Joe Python" whose needs
> neatly encapsulate the sum of all Python users' needs. There's plenty of
> evidence from this group that different people like, want or need
> different things from Python, and attempting to measure user
> requirements by democratic means is not likely to produce much useful
> information.
>
> There is no such thing as "the average Python programmer": an average
> can only be measured for one-dimensional values on some sort of linear
> continuum. Python users live in a multi-dimensional space where the
> concept of an average has little meaning and less use.

You've confused dimensions with modes.  There is such thing as the
center of a bivariate distribution--- it is merely the most common of
the individual variables, the top of a 3-D hill, or the center of
mass.

However, an average only makes sense for unimodal distributions.  If
the distribution is bi-modal, there's no "average" in the neat sense.

Dollars earned per hour spent writing in Python is a good candidate.
There are two modes in that distribution.  One at 0, the other in the
tens or hundreds.  And the global average is less common than either
mode individually.  So in this case, we have one "Joe Py" for every
mode: Joe Free Py, and Joe Paid Py.  (You might actually get multi-
modal on that one-- Joe Salary Py, Joe Wage Py, Joe Stipend Py, Joe
Free Py, but $0.01/hr. is less common than 0, and less common than
$50.)

You might also argue that the standard deviation is so high as to make
any one data point unrepresentative of many others.  But if you have
variables in two dimensions, they're independent by definition (or
there exists a basis set that is).
--
http://mail.python.org/mailman/listinfo/python-list

Re: How to read stdout from subprocess as it is being produced

[Alex]

On Dec 19, 5:09 pm, Albert Hopkins  wrote:
> On Fri, 2008-12-19 at 06:34 -0800, Alex wrote:
> > Hi,
>
> > I have a Pyhon GUI application that launches subprocess.
> > I would like to read the subprocess' stdout as it is being produced
> > (show it in GUI), without hanging the GUI.
>
> > I guess threading will solve the no-hanging issue, but as far as I
> > searched for now, I've only seen how to read the stdout after
> > subprocess is finished.
>
> I believe that's going to be highly dependent upon the particular, yet
> unspecified, GUI toolkit/API.
>
> There are probably a few ways. You're toolkit might native support for
> this, but one way would be to use a timer.  Here is some pseudocode:
>
> class MyWindow(toolkit.Window):
>     def __init__(self, ...):
>         ...
>         self.subprocess = subprocess.Popen(..., stdout=subprocess.PIPE)
>         self.running = True
>
>         ...
>         toolkit.set_timeout(TIMEOUT_VAL, self.read_stdout)
>
>     def read_stdout(self, ...):
>         if not self.running:
>             return
>         char = self.subprocess.stdout.read(1)
>         if char == '':
>             self.running = False
>             return
>         self.update_something(char)
>         toolkit.set_timeout(TIMEOUT_VAL, self.read_stdout)

Hi,

Thanks a lot for the tip!

Alex
--
http://mail.python.org/mailman/listinfo/python-list

Re: New Python 3.0 string formatting - really necessary?

[Aaron Brady]

On Dec 21, 7:34 am, Marc 'BlackJack' Rintsch  wrote:
> On Sun, 21 Dec 2008 12:45:32 +, Duncan Booth wrote:
> > You seem to have made an unwarranted assumption, namely that a binary
> > operator has to compile to a function with two operands. There is no
> > particular reason why this has to always be the case: for example, I
> > believe that C# when given several strings to add together optimises
> > this into a single call to a concatenation method.
>
> > Python *could* do something similar if the appropriate opcodes/methods
> > supported more than two arguments:
>
> > a+b+c+d might execute a.__add__(b,c,d) allowing more efficient string
> > concatenations or matrix operations, and a%b%c%d might execute as
> > a.__mod__(b,c,d).
>
> But that needs special casing strings and ``%`` in the comiler, because
> it might not be always safe to do this on arbitrary objects.  Only in
> cases where the type of `a` is known at compile time and ``a % b``
> returns an object of ``type(a)``.

'x+y' makes no guarantees whatsoever.  It could return an object of
type(x), type(y), or neither.  'a%b' in the case of strings is just,
str.__mod__, returning string.

In a+b+c, 'a' gets dibs over what the rest see, so there's no more
danger in the multi-ary case, than in binary; and that hasn't stopped
us before.

You might be confusing the cases of arbitrary operators vs. uniform
operators.  'a' does not get dibs in 'a+b*c'; 'b*c' are allowed to
carry out their affairs.  But in 'a+b+c', 'a*b*c', 'a%b%c', and so on,
'a' has final say on b's and c's behaviors via its return value, so
loses nothing by combining such a call.

In short, you can force it anyway, so it's syntactic sugar after that.
--
http://mail.python.org/mailman/listinfo/python-list

Re: New Python 3.0 string formatting - really necessary?

[Duncan Booth]

Steven D'Aprano  wrote:

>> a+b+c+d might execute a.__add__(b,c,d) allowing more efficient string
>> concatenations or matrix operations, and a%b%c%d might execute as
>> a.__mod__(b,c,d).
> 
> That's only plausible if the operations are associative. Addition is 
> associative, but string interpolation is not:

Addition is not associative on arbitrary types.

> 
 "%%%s" % ("%s" % "b")
> '%b'
 ("%%%s" % "%s") % "b"
> Traceback (most recent call last):
>   File "", line 1, in 
> TypeError: not all arguments converted during string formatting
> 
> Since string interpolation isn't associative, your hypothetical
> __mod__ method might take multiple arguments, but it would have to
> deal with them two at a time, unlike concatenation where the compiler
> could do them all at once. So whether __mod__ takes two arguments or
> many is irrelevant: its implementation must rely on some other
> function which takes two arguments and must succeed or fail on that.

I don't see that. What I suggested was that a % b % c would map to 
a.__mod__(b,c). (a % b) % c would also map to that, but a % (b % c) could 
only possibly map to a.__mod__(b.__mod__(c))

--
http://mail.python.org/mailman/listinfo/python-list

Re: New Python 3.0 string formatting - really necessary?

[Duncan Booth]

Marc 'BlackJack' Rintsch  wrote:

>> a+b+c+d might execute a.__add__(b,c,d) allowing more efficient string
>> concatenations or matrix operations, and a%b%c%d might execute as
>> a.__mod__(b,c,d).
> 
> But that needs special casing strings and ``%`` in the comiler, because 
> it might not be always safe to do this on arbitrary objects.  Only in 
> cases where the type of `a` is known at compile time and ``a % b`` 
> returns an object of ``type(a)``.
> 
I could be wrong, but I don't see that would be the case.

I think it would be safe (in this hypothetical universe) any time that 'a' 
had a method __mod__ which accepted more than one argument.

It might be simpler if I'd suggested an imaginary __mmod__ method so the 
opcode for multiple-mod could check for that method or fall back to doing 
mod of the first two values and then mmod of the result and any remaining 
values until only two remain.
--
http://mail.python.org/mailman/listinfo/python-list

Re: trapping all method calls in a class...

[Bruno Desthuilliers]

Chris Rebert a écrit :
(snip)


Sidenotes about your code:
- `args` and `kwds` are the conventional names for the * and **
special arguments


for '**', the most "conventional" names (at least the one I usually see) 
are 'kwargs', then 'kw'


--
http://mail.python.org/mailman/listinfo/python-list

Re: a small doubt

[Bruno Desthuilliers]

(answering to the OP)


Piyush Anonymous wrote:

i wrote this code
--
class Person(object):
instancesCount = 0
def __init__(self, title=""):
Person.instancesCount += 1
self.id  = "tempst"
def testprint(self):
print "blah blah"
def __getattribute__(self, name):
print "in get attribute"

a = Person()
a.testprint()
print a.id 
-
but i am getting this error

in get attribute
Traceback (most recent call last):
  File "trapmethodcall1.py", line 15, in 
a.testprint()
TypeError: 'NoneType' object is not callable
--
why is it so? __getattribute__ is called whenever an attribute or 
method is called, rt?



Yes. Methods are attributes too.  And __getattribute__ is the attribute 
lookup operator implementation - it is invoked *everytime* you have 
obj.attr or getattr(obj, "attr") or hasattr(obj, "attr"). IOW, you'd 
better *not* touch it unless 1/ you really know what you're doing, 2/ 
you have a very compelling reason to do so and 3/ you're ok to pay the 
performance hit (the default implementation in 'object' being optimized).



or if i set __getattribute__ , i cannot have 
methods in class?


Yes, you can. But you have to write a proper implementation of 
__getattribute__. The one above will prevent you from accessing any 
class or instance attribute (or, more exactly, will always return None).


actually my aim is to trap all method calls and keep a counter which 
is update whenever method called or returned. how should i go about it?



Using __getattribute__, you'll only get at the method when it is looked 
up (which doesn't imply it will be called). If you want to log calls and 
returns, you'll have to wrap the method in a decorator. You can do this 
either manually (ie manually adding the logger decorator on methods), 
via monkeypatching on class objects (but this can be tricky too), or 
adding a properly implemented version of __getattribute__ (but this 
won't work if the method is looked up on the class itself)


# a Q&D method call logger

def log(meth):
if hasattr(meth, "logged"):
# already wrapped
return meth

def logged(*args, **kw):
if hasattr(meth, "im_self"):
# wrapping a method
what = "method %s " % meth
else:
# wrapping a function, 'self' or 'cls' is the first arg
what = "method %s of object %s" % (meth, args[0])
print "%s called with %s %s" % (what, str(args), kw)
try:
result = meth(*args, **kw)
except Exception, e:
print "%s raised %s" % (what, e)
raise
else:
print "%s returned %s" % (what, str(result))
return result
logged.logged = True
return logged


# manual decoration

class Foo(object):
@log
def bar(self):
pass


# using __getattribute__

class Foo(object):
def bar(self):
pass
def __getattribute__(self, name):
attr = super(Foo2, self).__getattribute__(name)
if hasattr(attr, "im_self"):
attr = log(attr)
return attr



Given the shortcomings of the __getattribute__ version (performance hit 
and only triggered on instance lookup), I'd strongly suggest the manual 
decoration - possibly using a flag (global setting or environment 
variable) to switch it off, ie:


if globals().get("DEBUG", False):
def log(func):
def logged(*args, **kw):
# wrapping a function
# we assume this function is used as a method, so
# 'self' or 'cls' is the first arg
what = "method %s of object %s" % (func, args[0])
print "%s called with %s %s" % (what, str(args), kw)
try:
result = func(*args, **kw)
except Exception, e:
print "%s raised %s" % (what, e)
raise
print "%s returned %s" % (what, str(result))
return result
return logged
else:
def log(func):
# no-op
return func

NB : all this is pretty Q&D and mostly untested, but it should get you 
started.



HTH
--
http://mail.python.org/mailman/listinfo/python-list

Re: New Python 3.0 string formatting - really necessary?

[skip]

Marc> Many newbie code I have seen avoids it by string concatenation:

Marc> greeting = 'Hello, my name is ' + name + ' and I am ' + str(age) + ' 
old.'

Marc> That's some kind of indirect complaint.  :-)

I see Python code like that written by people with a C/C++ background.  I
don't think you can necessarily chalk that up to %-string avoidance.  They
learn that + will concatenate two strings and don't look further.

-- 
Skip Montanaro - s...@pobox.com - http://smontanaro.dyndns.org/
--
http://mail.python.org/mailman/listinfo/python-list

Re: New Python 3.0 string formatting - really necessary?

[Steve Holden]

r wrote:
> On Dec 20, 11:11 pm, walterbyrd  wrote:
>> On Dec 20, 5:05 pm, Roy Smith 
>>
>>> He got really hung up on the % syntax.
>> I guess it's good to know that there is, at least, one person in the
>> world doesn't like the % formatting. As least the move was not
>> entirely pointless.
>>
>> But, you must admit, of all the things people complain about with
>> Python, the % formatting is probably one of the least common
>> complaints. Complaints about Python's speed seem much more common.
>>
>> Yet, 3.0 makes the speed worse, and "fixes" a non-problem.
>>
>> I can see where the new formatting might be helpful in some cases.
>> But, I am not sure it's worth the cost.
> 
> This all really comes down to the new python users. Yea, i said it.
> Not rabid fanboys like Steven and myself.(i can't speak for walter but
> i think he would agree) Are we going to make sure joe-blow python
> newbie likes the language. And doesn't get turned off and run over to
> ruby or whoever. Like it or not, without newusers python is doomed to
> the same fate as all the other "great" languages who had their 15 mins
> of fame.
> 
> We must proactively seek out the wants of these new users and make
> sure python stays alive. But we also must not sell are pythonic souls

 that's "our" (possessive), r, not "are" (verb)
> in the process.
> 
> It would be nice to get a vote together and see what does the average
> pythoneer want? What do they like, What do they dislike. What is the
> state of the Python Union? Does anybody know, Does anybody care? I
> think python is slipping away from it's dominate foothold on the
> world. Google's use of python may be the only thing holding this house
> of cards together. Ruby's "hype" is defiantly growing and unless we
> strive for greatness, python may fail. I think ruby may have their act
> together a little better than us right now. And since Ruby is such a
> hodge-podge of different languages, the __init__ hold is there for
> many.
> 
> what does joe-python want???

Don't make the mistake of assuming there is a "Joe Python" whose needs
neatly encapsulate the sum of all Python users' needs. There's plenty of
evidence from this group that different people like, want or need
different things from Python, and attempting to measure user
requirements by democratic means is not likely to produce much useful
information.

There is no such thing as "the average Python programmer": an average
can only be measured for one-dimensional values on some sort of linear
continuum. Python users live in a multi-dimensional space where the
concept of an average has little meaning and less use.

As for your assertion that Google's use of Python may be the only thing
maintaining Python's popularity, it's complete twaddle. Take a look
around at who's involved in using Python. I suspect Industrial Light and
Magic ,may have more Python programmers than Google, who also make
extensive use of Java and one other language (C++?), as well as a bevy
of others as justified by project needs. Rackspace, NASA, Canonical and
many others are keen supporters of the language, and they put their
money where their mouths are by incorporating it into their products.

regards
 Steve
-- 
Steve Holden+1 571 484 6266   +1 800 494 3119
Holden Web LLC  http://www.holdenweb.com/

--
http://mail.python.org/mailman/listinfo/python-list

Re: C API and memory allocation

[Hrvoje Niksic]

Aaron Brady  writes:

> I hold this is strong enough to put the burden of proof on the
> defenders of having 's'.  What is its use case?

Passing the string to a C API that can't handle (or don't care about)
embedded null chars anyway.  Filename API's are a typical example.
--
http://mail.python.org/mailman/listinfo/python-list

www.iofferkicks.com china cheap wholesale nike shoes,air jordan shoes,air force one shoes.

[www.iofferkicks.com]

Get Nike Shoes at Super Cheap Prices
Discount Nike air jordans  (www.iofferkicks.com)
Discount Nike Air Max 90 Sneakers  (www.iofferkicks.com)
Discount Nike Air Max 91 Supplier  (www.iofferkicks.com)
Discount Nike Air Max 95 Shoes Supplier  (www.iofferkicks.com)
Discount Nike Air Max 97 Trainers  (www.iofferkicks.com)
Discount Nike Air Max 2003 Wholesale  (www.iofferkicks.com)
Discount Nike Air Max 2004 Shoes Wholesale
(www.iofferkicks.com)
Discount Nike Air Max 2005 Shop  (www.iofferkicks.com)
Discount Nike Air Max 2006 Shoes Shop  (www.iofferkicks.com)
Discount Nike Air Max 360 Catalogs  (www.iofferkicks.com)
Discount Nike Air Max Ltd Shoes Catalogs  (www.iofferkicks.com)
Discount Nike Air Max Tn Men's Shoes  (www.iofferkicks.com)
Discount Nike Air Max Tn 2 Women's Shoes  (www.iofferkicks.com)
Discount Nike Air Max Tn 3 Customize  (www.iofferkicks.com)
Discount Nike Air Max Tn 4 Shoes Customize
( www.iofferkicks.com)
Discount Nike Air Max Tn 6 Supply  (www.iofferkicks.com)
Discount Nike Shox NZ Shoes Supply  (www.iofferkicks.com)
Discount Nike Shox OZ Sale  (www.iofferkicks.com)
Discount Nike Shox TL Store  (www.iofferkicks.com)
Discount Nike Shox TL 2 Shoes Store (www.iofferkicks.com)
Discount Nike Shox TL 3 Distributor (www.iofferkicks.com)
Discount Nike Shox Bmw Shoes Distributor  (www.iofferkicks.com)
Discount Nike Shox Elite Shoes Manufacturer
(www.iofferkicks.com)
Discount Nike Shox Monster Manufacturer  (www.iofferkicks.com)
Discount Nike Shox R4 Running Shoes  (www.iofferkicks.com)
Discount Nike Shox R5 Mens Shoes  (www.iofferkicks.com)
Discount Nike Shox Ride Womens Shoes (www.iofferkicks.com)
Discount Nike Shox Rival Shoes Wholesaler  (www.iofferkicks.com)
Discount Nike Shox Energia Wholesaler  (www.iofferkicks.com)
Discount Nike Shox LV Sneaker  (www.iofferkicks.com)
Discount Nike Shox Turbo Suppliers  (www.iofferkicks.com)
Discount Nike Shox Classic Shoes Suppliers
(www.iofferkicks.com)
Discount Nike Shox Dendara Trainer  (www.iofferkicks.com)
Discount Nike Air Jordan 1 Seller  (www.iofferkicks.com)
Discount Nike Air Jordan 2 Shoes Seller  (www.iofferkicks.com)
Discount Nike Air Jordan 3 Collection  (www.iofferkicks.com)
Discount Nike Air Jordan 4 Shoes Collection
(www.iofferkicks.com)
Discount Nike Air Jordan 5 Chaussure Shoes
(www.iofferkicks.com)
Discount Nike Air Jordan 6 Catalog  (www.iofferkicks.com)
Discount Nike Air Jordan 7 Shoes Catalog  (www.iofferkicks.com)
Discount Nike Air Jordan 8 Customized  (www.iofferkicks.com)
Discount Nike Air Jordan 9 Shoes Customized
(www.iofferkicks.com)
Discount Nike Air Jordan 10 Wholesalers  (www.iofferkicks.com)
Discount Nike Jordan 11 Shoes Wholesalers (www.iofferkicks.com)
Discount Nike Air Jordan 12 Factory  (www.iofferkicks.com)
Discount Nike Air Jordan 13 Shoes Factory (www.iofferkicks.com)
Discount Nike Air Jordan 14 Shoes Sell  (www.iofferkicks.com)
Discount Nike Air Jordan 16 Exporter  (www.iofferkicks.com)
Discount Nike Air Jordan 17 Shoes Exporter
(www.iofferkicks.com)
Discount Nike Air Jordan 18 Offer  (www.iofferkicks.com)
Discount Nike Air Jordan 19 Shoes Offer  (www.iofferkicks.com)
Discount Nike Air Jordan 20 Manufacture  (www.iofferkicks.com)
Discount Nike Jordan 21 Shoes Manufacture  (www.iofferkicks.com)
EMAIL:iofferki...@gmail.com
MSN :iofferki...@msn.com
--
http://mail.python.org/mailman/listinfo/python-list

Re: New Python 3.0 string formatting - really necessary?

[Steven D'Aprano]

On Sun, 21 Dec 2008 12:45:32 +, Duncan Booth wrote:

> Steven D'Aprano  wrote:
> 
>> Errors should never pass silently, unless explicitly silenced. You have
>> implicitly silenced the TypeError you get from not having enough
>> arguments for the first format operation. That means that you will
>> introduce ambiguity and bugs.
>> 
>> "%i %i %i %i" % 5 % 3 %7
>> 
>> Here I have four slots and only three numbers. Which output did I
>> expect?
>> 
>> '%i 5 3 7'
>> '5 %i 3 7'
>> '5 3 %i 7'
>> '5 3 7 %i'
>> 
>> Or more likely, the three numbers is a mistake, there is supposed to be
>> a fourth number there somewhere, only now instead of the error being
>> caught immediately, it won't be discovered until much later.
>> 
> You seem to have made an unwarranted assumption, namely that a binary
> operator has to compile to a function with two operands. There is no
> particular reason why this has to always be the case: for example, I
> believe that C# when given several strings to add together optimises
> this into a single call to a concatenation method.

[...]

> Python *could* do something similar if the appropriate opcodes/methods
> supported more than two arguments:
> 
> a+b+c+d might execute a.__add__(b,c,d) allowing more efficient string
> concatenations or matrix operations, and a%b%c%d might execute as
> a.__mod__(b,c,d).

That's only plausible if the operations are associative. Addition is 
associative, but string interpolation is not:

>>> "%%%s" % ("%s" % "b")
'%b'
>>> ("%%%s" % "%s") % "b"
Traceback (most recent call last):
  File "", line 1, in 
TypeError: not all arguments converted during string formatting

Since string interpolation isn't associative, your hypothetical __mod__ 
method might take multiple arguments, but it would have to deal with them 
two at a time, unlike concatenation where the compiler could do them all 
at once. So whether __mod__ takes two arguments or many is irrelevant: 
its implementation must rely on some other function which takes two 
arguments and must succeed or fail on that.

Either that, or we change the design of % interpolation, and allow it to 
silently ignore errors. I assumed that is what Aaron wanted.


 
> In that alternate universe your example:
> 
>   "%i %i %i %i" % 5 % 3 %7
> 
> simply throws "TypeError: not enough arguments for format string"

That has a disturbing consequence.

Consider that most (all?) operations, we can use temporary values:

x = 1 + 2 + 3 + 4
=> x == 10

gives the same value for x as:

temp = 1 + 2 + 3
x = temp + 4

I would expect that the same should happen for % interpolation:

# using Aaron's hypothetical syntax
s = "%s.%s.%s.%s" % 1 % 2 % 3 % 4
=> "1.2.3.4"

should give the same result as:

temp = "%s.%s.%s.%s" % 1 % 2 % 3
s = temp % 4

But you're arguing that the first version should succeed and the second 
version, using a temporary value, should fail. And that implies that if 
you group part of the expression in parentheses, it will fail as well:

s = ("%s.%s.%s.%s" % 1 % 2 % 3) % 4

Remove the parentheses, and it succeeds. That's disturbing. That makes 
the % operator behave very differently from other operators.

Note that with the current syntax, we don't have that problem: short-
supplying arguments leads to an exception no matter what.


>   "%s" % (1,2,3)
> 
> just converts the tuple as a single argument. It also provides the
> answer to how you put a percent in the format string (double it) 

I trust you know that already works, but just in case:

>>> "%g%%" % 12.5
'12.5%'

> and what happens if a substitution inserts a percent (it doesn't
> interact with the formatting operators).

Ditto:

>>> "%s" % "%g"
'%g'



-- 
Steven
--
http://mail.python.org/mailman/listinfo/python-list

Re: Read an image from a URL and write it to the browser

[McCoy Fan]

On Dec 21, 7:25 am, Peter Otten <__pete...@web.de> wrote:
> McCoy Fan wrote:
> > I want to do something simple: read an image from an image URL and
> > write the image to the browser in CGI style.
>
> > I wrote a CGI script to do this (I'm new to Python) and got the
> > following error:
>
> > "FancyURLopener instance has no attribute 'tempcache'" in  > method FancyURLopener.__del__ of 
> > I have no idea what that error means and neither does Google.
>
> > Any idea where I went wrong in the code below?
> > import urllib
>
> > urlString = "http://www.google.com/google_logo.jpg";
> > imgStream = urllib.urlopen(urlString)
> > imgBuffer = imgStream.read()
> > imgStream.close()
> > print "Content-Type: image/jpeg"
> > print
> > print imgBuffer
>
> Your script runs without error here, but I can  provoke the attribute error
> by passing an invalid proxies argument to urlopen():
>
> $ python -c"import urllib; urllib.urlopen('whatever', proxies=42)"
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/usr/lib/python2.5/urllib.py", line 75, in urlopen
>     opener = FancyURLopener(proxies=proxies)
>   File "/usr/lib/python2.5/urllib.py", line 609, in __init__
>     URLopener.__init__(self, *args, **kwargs)
>   File "/usr/lib/python2.5/urllib.py", line 117, in __init__
>     assert hasattr(proxies, 'has_key'), "proxies must be a mapping"
> AssertionError: proxies must be a mapping
> Exception exceptions.AttributeError: "FancyURLopener instance has no
> attribute 'tempcache'" in  > ignored
>
> Please post your complete traceback, Python version, and OS to allow for a
> more detailed diagnosis.
>
> You can also try to run your script with
>
> > imgStream = urllib.urlopen(urlString)
>
> changed to
>
> imgStream = urllib.urlopen(urlString, proxies={})
>
> to bypass the code in which I suppose the failure to occur.
>
> Peter

I appreciate your response. Thank you.

After reading your reply, I realized this must be related to the fact
that I am running this script on Google App Engine.

It turns out, App Engine does not allow direct socket communication so
urllib is not allowed.

Instead they provide their own library called urlfetch. So my script
should look something like this:

from google.appengine.api import urlfetch
print 'Content-Type: text/plain'
print ''
result = urlfetch.fetch('http://www.google.com/google_logo.jpg')
print result.content

I haven't been able to get it to work yet but at least I'm heading in
the right direction now. I'll keep digging. Thanks!
--
http://mail.python.org/mailman/listinfo/python-list

Re: New Python 3.0 string formatting - really necessary?

[Marc 'BlackJack' Rintsch]

On Sun, 21 Dec 2008 12:45:32 +, Duncan Booth wrote:

> You seem to have made an unwarranted assumption, namely that a binary
> operator has to compile to a function with two operands. There is no
> particular reason why this has to always be the case: for example, I
> believe that C# when given several strings to add together optimises
> this into a single call to a concatenation method.
> 
> Python *could* do something similar if the appropriate opcodes/methods
> supported more than two arguments:
> 
> a+b+c+d might execute a.__add__(b,c,d) allowing more efficient string
> concatenations or matrix operations, and a%b%c%d might execute as
> a.__mod__(b,c,d).

But that needs special casing strings and ``%`` in the comiler, because 
it might not be always safe to do this on arbitrary objects.  Only in 
cases where the type of `a` is known at compile time and ``a % b`` 
returns an object of ``type(a)``.

Ciao,
Marc 'BlackJack' Rintsch
--
http://mail.python.org/mailman/listinfo/python-list

Re: New Python 3.0 string formatting - really necessary?

[Duncan Booth]

Steven D'Aprano  wrote:

> Errors should never pass silently, unless explicitly silenced. You
> have implicitly silenced the TypeError you get from not having enough 
> arguments for the first format operation. That means that you will 
> introduce ambiguity and bugs.
> 
> "%i %i %i %i" % 5 % 3 %7
> 
> Here I have four slots and only three numbers. Which output did I
> expect? 
> 
> '%i 5 3 7'
> '5 %i 3 7'
> '5 3 %i 7'
> '5 3 7 %i'
> 
> Or more likely, the three numbers is a mistake, there is supposed to
> be a fourth number there somewhere, only now instead of the error
> being caught immediately, it won't be discovered until much later.
> 
You seem to have made an unwarranted assumption, namely that a binary 
operator has to compile to a function with two operands. There is no 
particular reason why this has to always be the case: for example, I 
believe that C# when given several strings to add together optimises this 
into a single call to a concatenation method.

Python *could* do something similar if the appropriate opcodes/methods 
supported more than two arguments:

a+b+c+d might execute a.__add__(b,c,d) allowing more efficient string 
concatenations or matrix operations, and a%b%c%d might execute as 
a.__mod__(b,c,d).

In that alternate universe your example:

"%i %i %i %i" % 5 % 3 %7

simply throws "TypeError: not enough arguments for format string", and

  "%s" % (1,2,3)

just converts the tuple as a single argument. It also provides the answer 
to how you put a percent in the format string (double it) and what happens 
if a substitution inserts a percent (it doesn't interact with the 
formatting operators).
--
http://mail.python.org/mailman/listinfo/python-list

Re: Read an image from a URL and write it to the browser

[Peter Otten]

McCoy Fan wrote:

> I want to do something simple: read an image from an image URL and
> write the image to the browser in CGI style.
> 
> I wrote a CGI script to do this (I'm new to Python) and got the
> following error:
> 
> "FancyURLopener instance has no attribute 'tempcache'" in  method FancyURLopener.__del__ of  
> I have no idea what that error means and neither does Google.
> 
> Any idea where I went wrong in the code below?

> import urllib
> 
> urlString = "http://www.google.com/google_logo.jpg";
> imgStream = urllib.urlopen(urlString)
> imgBuffer = imgStream.read()
> imgStream.close()
> print "Content-Type: image/jpeg"
> print
> print imgBuffer

Your script runs without error here, but I can  provoke the attribute error
by passing an invalid proxies argument to urlopen():

$ python -c"import urllib; urllib.urlopen('whatever', proxies=42)"
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.5/urllib.py", line 75, in urlopen
opener = FancyURLopener(proxies=proxies)
  File "/usr/lib/python2.5/urllib.py", line 609, in __init__
URLopener.__init__(self, *args, **kwargs)
  File "/usr/lib/python2.5/urllib.py", line 117, in __init__
assert hasattr(proxies, 'has_key'), "proxies must be a mapping"
AssertionError: proxies must be a mapping
Exception exceptions.AttributeError: "FancyURLopener instance has no
attribute 'tempcache'" in > ignored

Please post your complete traceback, Python version, and OS to allow for a
more detailed diagnosis.

You can also try to run your script with

> imgStream = urllib.urlopen(urlString)

changed to

imgStream = urllib.urlopen(urlString, proxies={})

to bypass the code in which I suppose the failure to occur.

Peter
--
http://mail.python.org/mailman/listinfo/python-list

HMAC with RIPEMD-160

[Kless]

Is there any way of use HMAC with RIPEMD-160?

Since that to create a ripemd-160 hash there is to use:
h = hashlib.new('ripemd160')
it looks that isn't possible

For HMAC-SHA256 would be:
-
import hashlib
import hmac

hm = hmac.new('key', msg='message', digestmod=hashlib.sha256)
-


http://docs.python.org/library/hashlib.html
http://docs.python.org/library/hmac.html
--
http://mail.python.org/mailman/listinfo/python-list

RE: Best Practice using Glade/Python (ericericaro: message 1 of 20)

[Barak, Ron]

Hi Eric,

Once the UI is defined, you interface to events as usual, e.g.:

def OnSelChanged(self, evt):
self.tablecont = str(self.GetItemText(evt.GetItem()))
self.dprint(line()+". OnSelChanged:", self.tablecont)
self.TreeViewController(self.tablecont)
self.Bind(wx.EVT_TREE_SEL_CHANGED, self.OnSelChanged, self.tree)
Bye,
Ron.

P.S.: I think you'd get better responses if you asked this question on 
wxpython-us...@lists.wxwidgets.org


From: Eric Atienza - e...@ericaro.net 
[mailto:+ericericaro+comverse+2e4452f01c.eric#ericaro@spamgourmet.com]
Sent: Thursday, December 18, 2008 15:47
To: ericericaro.comve...@9ox.net
Subject: Re: Best Practice using Glade/Python (ericericaro: message 1 of 20)

Hi, thank for the response (but it ain't in the usenet).

I'm looking for best pratices about connecting 'events' from a glade defined 
UI, and python code.

How to you manage it ?



Eric
http://codeslash.blogspot.com

On Thu, Dec 18, 2008 at 2:25 PM, 
mailto:ericericaro.comve...@9ox.net>> wrote:
Hi Eric,
I'm not sure if I answer your question, but I designed wxPython GUI with 
wxGlade (http://wiki.wxpython.org/wxGlade).
Bye,
Ron.

-Original Message-
From: eric [mailto:e...@ericaro.net]
Sent: Thursday, December 18, 2008 12:39
To: python-list@python.org
Subject: Best Practice using Glade/Python

Hi,

I was wondering which is the "best practice" using glade/python, and, of 
course, especially the connect (both side).

I didn't found that much documentation on the net ( too noisy), and the best 
"thing" I've found was http://www.linuxjournal.com/article/7558
which is a bit old now (2004). The article is very interesting BTW, but I was 
concerned by the fact it might be a little outdated.

It smells like I'm missing something here, and that there have been a clean way 
to connect both (the autoconnect stuff does not seem that clean to me) for a 
long time now.

So here is the question, do you practive galde/python, which is your practice ?

Thanks


Eric
http://codeslash.blogspot.com



--
http://mail.python.org/mailman/listinfo/python-list

Re: New Python 3.0 string formatting - really necessary?

[Aaron Brady]

On Dec 20, 8:49 pm, MRAB  wrote:
> Aaron Brady wrote:
> > On Dec 20, 7:38 pm, Steven D'Aprano  > cybersource.com.au> wrote:
> >> Instead of just whinging, how about making a suggestion to fix it? Go on,
> >> sit down for an hour or ten and try to work out how a BINARY OPERATOR
> >> like % (that means it can only take TWO arguments) can deal with an
> >> arbitrary number of arguments, *without* having any special cases.
>
> >> Go on. Take your time. I'll be waiting.
>
> > Hi, not to take sides, but, there is a possibility.
>
> > This behavior is currently legal:
>
>  "%i %%i" % 0 % 1
> > '0 1'
>
> > So, just extend it.  (Unproduced.)
>
>  "%i %i" % 0 % 1
> > '0 1'
>  "%r %i" % (2, 3, 4) % 1
> > '(2, 3, 4) 1'
>  "%r %i" % (2, 3, 4)
> > '(2, 3, 4) %i'
>
> > Which is quite clever and way ahead of its (posessive) time.
>
> A couple of problems:
>
> 1. How do you handle a literal '%'? If you just double up then you'll
> need to fix the string after all your substitutions.
>
> 2. What if a substitution introduces a '%'?
>
> I suppose a possible solution would be to introduce a special format
> string, including a literal, eg:
>
>      f"%r %i" % (2, 3, 4) % 1
>
> and then convert the result to a true string:
>
>      print(str(f"%r %i" % (2, 3, 4) % 1))
>
> (although print() would call __str__ anyway).
>
> The format string would track where the last substitution occurred.
>
> Hmm... I think I'll just learn the new method. :-)

Now that I'm fighting 'r's war for him/her...

Um, here's one possibility.  On the first interpolation, flags are
noted and stored apart from subsequent interpolations.  Then, use a
sentinel to terminate the interpolation.  (Unproduced.)

>>> "%r %i" % ( 2, 3 ) % 0
'(2, 3) 0'
>>> "%% %r" % ( 2, 3 ) % str.interp_end
'% (2, 3)'
>>> "%sss%i" % "%d" % 0
'%dss0'

The first %s is replaced with %d, but doesn't hijack the '0'.  If you
want to interpolate the %d, use the sentinel.  The sentinel is what
causes '%%' to be handled.

>>> "%sss%i" % "%d" % 0 % 1
Traceback (most recent call last):
  File "", line 1, in 
TypeError: not all arguments converted during string formatting
>>> "%sss%i" % "%d" % 0 % str.interp_end % 1
'1ss0'

Treating tuples as a special case appears to be the simpler solution,
but this, 'chaining', to adopt the term, is still feasible.
--
http://mail.python.org/mailman/listinfo/python-list

Read an image from a URL and write it to the browser

[McCoy Fan]

I want to do something simple: read an image from an image URL and
write the image to the browser in CGI style.

I wrote a CGI script to do this (I'm new to Python) and got the
following error:

"FancyURLopener instance has no attribute 'tempcache'" in http://www.google.com/google_logo.jpg";
imgStream = urllib.urlopen(urlString)
imgBuffer = imgStream.read()
imgStream.close()
print "Content-Type: image/jpeg"
print
print imgBuffer
--
http://mail.python.org/mailman/listinfo/python-list

Re: New Python 3.0 string formatting - really necessary?

[Aaron Brady]

On Dec 20, 8:26 pm, Steven D'Aprano  wrote:
> On Sat, 20 Dec 2008 17:55:35 -0800, Aaron Brady wrote:
snip
> > This behavior is currently legal:
>
>  "%i %%i" % 0 % 1
> > '0 1'
>
> > So, just extend it.  (Unproduced.)
>
>  "%i %i" % 0 % 1
> > '0 1'
>
> Errors should never pass silently, unless explicitly silenced. You have
> implicitly silenced the TypeError you get from not having enough
> arguments for the first format operation. That means that you will
> introduce ambiguity and bugs.

No, it's not part of the (new) '%' operation.  '%' handles one flag at
a time.  It's not an error if the author intends it.

> "%i %i %i %i" % 5 % 3 %7
>
> Here I have four slots and only three numbers. Which output did I expect?
>
> '%i 5 3 7'
> '5 %i 3 7'
> '5 3 %i 7'
> '5 3 7 %i'

Anything, so long as it's (contraction) consistent and general.

> Or more likely, the three numbers is a mistake, there is supposed to be a
> fourth number there somewhere, only now instead of the error being caught
> immediately, it won't be discovered until much later.

Leave that to unit testing and your QA team.

To make the change, the burden of proof (which is large) would fall to
me.  However, in the abstract case, it's not clear that either one is
favorable, more obvious, or a simpler extrapolation.

Bug-proneness is an argument against a construction, just not a
conclusive one.  How heavy is it in this case?
--
http://mail.python.org/mailman/listinfo/python-list

Re: How to transfer data structure or class from Python to C/C++?

[Aaron Brady]

On Oct 16, 9:10 am, Hongtian  wrote:
snip
> Not exactly.

> In my C/C++ application, I have following function or flow:

> void func1()
> {
> call PyFunc(struct Tdemo, struct &Tdemo1);
> }

> I mean I want to invoke Python function 'PyFunc' and transfer a data
> structure 'Tdemo' to this function. After some process in Python, I
> want it return 'Tdemo1' back to the C/C++ application.
snip

This is a correction of:
Oct 17, 5:03 pm, "Aaron \"Castironpi\" Brady" 
http://groups.google.com/group/comp.lang.python/msg/f11ac4a34faaf766
Thread:
http://groups.google.com/group/comp.lang.python/browse_thread/thread/68d59cb670a345ef

Revised solution uses 'from_address' instead of '_ctypes._cast_addr'.

import ng27ext

import ctypes as c
class TypeA( c.Structure ):
_fields_= [
( 'a', c.c_int ),
( 'b', c.c_float )
]

def exposed( pobj1, pobj2 ):
obj1= TypeA.from_address( pobj1 )
obj2= TypeA.from_address( pobj2 )
print obj1.a, obj1.b
obj2.a= c.c_int( 60 )
obj2.b= c.c_float( 65.5 )
print obj2.a, obj2.b

print ng27ext.methA( exposed )
--
http://mail.python.org/mailman/listinfo/python-list

Re: trapping all method calls in a class...

[Aaron Brady]

On Dec 21, 1:32 am, "Chris Rebert"  wrote:
> On Sat, Dec 20, 2008 at 11:12 PM, Piyush Anonymous
>
>  wrote:
> > hi,
> > i need to trap all method calls in a class in order to update a counter
> > which is increased whenever a method is called and decreased whenever method
> > returns. in order to that i am trying to write a decorator for all the
> > methods.
>
> > see the code here with error.
> > ---
> >http://codepad.org/2w7JVvDB
> > 
> > any suggestions? any other better way of doing it?
>
> I call unnecessary use of metaclasses! Here's my (untested) attempt at
> a simpler class decorator approach:
>
> def decorate_meths(klass):
>     attrs = klass.__dict__.items()
>         for name, val in attrs:
>                 if callable(val):
>                         klass.__dict__[name] = decorate(val)
>
> def decorate(method):
>     #should be called for every method call in the class
>     def decorated(self, *args, **kwds):
>         print "2 Inside __call__()"
>         returnval = method(self, *args,**kwds)
>         print "3 After self.f(*args)"
>         return returnval
>     return decorated
>
> #...@decorate_meths <-- this syntax requires a later Python version
> class Person(object):
>         def testprint(self,val):
>                 print "blah blah"
> Person = decorate_meths(Person)
>
> #rest of code after the class definition would be the same
>
> Sidenotes about your code:
> - `args` and `kwds` are the conventional names for the * and **
> special arguments
> - the `methodname` variable was actually getting method objects, not
> strings, as its values; this was probably part of the bug in your
> program
>
> Cheers,
> Chris
>
> --
> Follow the path of the Iguana...http://rebertia.com

Two more possibilities.

1.  Use sys.settrace, and a dictionary mapping functions to integers.
The functions are given in the frame object, which is a parameter to
the settrace function.

2.  __getattribute__, which either maps a function to an integer, and
returns the function; or returns a function that increments an
integer, then calls the requested function.

P.S.  I did not see the original post in Google Groups.
--
http://mail.python.org/mailman/listinfo/python-list

Re: New Python 3.0 string formatting - really necessary?

[Steven D'Aprano]

On Sun, 21 Dec 2008 00:57:46 -0800, Patrick Mullen wrote:

> 2) In my experience, major version changes tend to be slower than
> before.  When a lot of things change, especially if very low-level
> things change, as happened in python 3.0, the new code has not yet went
> through many years of revision and optimization that the old code has. 


I was around for the change from Python 1.5 -> 2.x. By memory, I skipped 
a couple of versions... I think I didn't make the move until Python 2.2 
or 2.3 was released. Python 2.0 was significantly slower than 1.5 in a 
number of critical areas, but not for long.

Actually, it's quite possible that Python 1.5 is still faster than Python 
2.x in some areas -- but of course it misses a lot of features, and at 
the end of the day, the difference between your script completing in 0.03 
seconds or in 0.06 seconds is meaningless.


> In my opinion, python 3 was rushed out the door a bit.  It could have
> done with a few more months of optimization and polishing. However, on
> the other hand, it is going to take so long for python infrastructure to
> convert to python 3, that an earlier release makes sense, even if it
> hasn't been excessively polished.  The biggest reason for the speed
> change is the rewritten stdio and unicode-everything.  Hopefully this
> stuff can be improved in future updates.  I don't think anyone WANTS
> cpython to be slower.

I understand that the 3.0.1 release due out around Christmas will have 
some major speed-ups in stdio.


-- 
Steven
--
http://mail.python.org/mailman/listinfo/python-list

Re: linecache vs egg - reading line of a file in an egg

[R. Bernstein]

Robert Kern  writes:

> R. Bernstein wrote:
>> Does linecache work with source in Python eggs? If not, is it
>> contemplated that this is going to be fixed or is there something else
>> like linecache that currently works?
>
> linecache works with eggs and other zipped Python source, but it had
> to extend the API in order to do so. Some of the debuggers don't use
> the extended API. This will be fixed in the next 2.6.x bugfix release,
> but not in 2.5.3.

Ok. I have committed a change in pydb sources to deal with the 2 and 3
argument linecache.getline interface which should cover Python
releases both before and after version 2.5.

>
> http://bugs.python.org/issue4201

Many thanks! I should have dug deeper myself.

For pdb/bdb though isn't there still a problem in reporting the file
location? There is that weird "build" name that seems to be stored in
func_code.co_filename mentioned in the original post. 

I just tried patching pdb/bdb along from the current 2.6 svn sources
and here is what I see:

  $ pdb /tmp/lc.py 
  > /tmp/lc.py(1)()
  -> import tracer
  (Pdb) s
  --Call--
  > /src/external-vcs/python/build/bdist.linux-i686/egg/tracer.py(6)()

The above filename is wrong. It's very possible I did something wrong,
so I'd be grateful if someone else double checked. 

Furthermore, if there is a problem I'm not sure I see how to fix this. 

I can think of heuristics to tell if module lives an inside an egg,
but is there a reliable way? Is there a standard convention for
reporting a file location inside of an egg? 

Thanks again.

>
> -- 
> Robert Kern
>
> "I have come to believe that the whole world is an enigma, a harmless enigma
>  that is made terrible by our own mad attempt to interpret it as though it had
>  an underlying truth."
>   -- Umberto Eco
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[Marc 'BlackJack' Rintsch]

On Sat, 20 Dec 2008 14:18:40 -0800, cm_gui wrote:

>> Seriously cm_gui, you're a fool.
>> Python is not slow.
> 
> haha, getting hostile?
> python fans sure are a nasty crowd.
> 
> Python is SLOW.
> 
> when i have the time, i will elaborate on this.

You are not fast enough to elaborate on Python's slowness!?  :-)

cm_gui is slow!

Ciao,
Marc 'BlackJack' Rintsch
--
http://mail.python.org/mailman/listinfo/python-list

Re: New Python 3.0 string formatting - really necessary?

[Marc 'BlackJack' Rintsch]

On Sat, 20 Dec 2008 15:27:43 -0800, walterbyrd wrote:

> On Dec 19, 10:25 am, Michael Torrie  wrote:
> 
>> Personally the new string formatter is sorely needed in Python.
> 
> Really? You know, it's funny, but when I read problems that people have
> with python, I don't remember seeing that. Loads of people complain
> about the white space issue. Some people complain  about the speed. Lots
> of complaints about certain quirky behavior, but I have not come across
> any complaints about the string formatting.

Many newbie code I have seen avoids it by string concatenation:

greeting = 'Hello, my name is ' + name + ' and I am ' + str(age) + ' old.'

That's some kind of indirect complaint.  :-)

> In fact, from what I have seen, many of the "problems" being "fixed"
> seem to be non-problems.

And even if nobody has problems with the limitations of ``%`` string 
formatting why shouldn't they add a more flexible and powerful way!?  
Python 3.0 is not a bug fix release.

Ciao,
Marc 'BlackJack' Rintsch
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python for amd64 and mingw-w64

[Martin v. Löwis]

> This is the only problem on python side of things to make extensions
> buildable on windows x64 (all the other problems I have encountered so
> far to make numpy build with mingw-w64 are numpy's or mingw-w64).

Thanks!

Martin
--
http://mail.python.org/mailman/listinfo/python-list

Re: New Python 3.0 string formatting - really necessary?

[Marc 'BlackJack' Rintsch]

On Sat, 20 Dec 2008 22:15:23 -0800, r wrote:

> It would be nice to get a vote together and see what does the average
> pythoneer want? What do they like, What do they dislike. What is the
> state of the Python Union? Does anybody know, Does anybody care? I think
> python is slipping away from it's dominate foothold on the world.
> Google's use of python may be the only thing holding this house of cards
> together. Ruby's "hype" is defiantly growing and unless we strive for
> greatness, python may fail. I think ruby may have their act together a
> little better than us right now. And since Ruby is such a hodge-podge of
> different languages, the __init__ hold is there for many.
> 
> what does joe-python want???

That's not completely irrelevant but I think one of Python's strength is 
that we have a BDFL who decides carefully what he thinks is best for the 
language instead of integrating every random idea some newbie comes up 
with and which might sound useful at first sight.

Python has its quirks but even with things I don't like I often realize 
later it was a wise decision that integrates well into the language 
whereas my ideas for "fixes" of the quirks wouldn't.  "joe-python" most 
often doesn't see the whole picture and demands changes that look easy at 
first sight, but are hard to implement right and efficient or just shifts 
the problem somewhere else where the next "joe-python" trips over it.

Ciao,
Marc 'BlackJack' Rintsch
--
http://mail.python.org/mailman/listinfo/python-list

Re: New Python 3.0 string formatting - really necessary?

[Patrick Mullen]

On Sat, Dec 20, 2008 at 10:15 PM, r  wrote:
> On Dec 20, 11:11 pm, walterbyrd  wrote:
>> On Dec 20, 5:05 pm, Roy Smith 
>>
>> > He got really hung up on the % syntax.
>>
>> I guess it's good to know that there is, at least, one person in the
>> world doesn't like the % formatting. As least the move was not
>> entirely pointless.
>>
>> But, you must admit, of all the things people complain about with
>> Python, the % formatting is probably one of the least common
>> complaints. Complaints about Python's speed seem much more common.
>>
>> Yet, 3.0 makes the speed worse, and "fixes" a non-problem.

A few points:
1) The new formatting is NOT the reason for the speed slowdown.  So
this change at least was a no cost change.  No cost to interpreter
speed, and no cost as it doesn't replace the old sprintf style.  Of
all the things to complain about in python 3.0, the format method is
the silliest.
2) In my experience, major version changes tend to be slower than
before.  When a lot of things change, especially if very low-level
things change, as happened in python 3.0, the new code has not yet
went through many years of revision and optimization that the old code
has.  In my opinion, python 3 was rushed out the door a bit.  It could
have done with a few more months of optimization and polishing.
However, on the other hand, it is going to take so long for python
infrastructure to convert to python 3, that an earlier release makes
sense, even if it hasn't been excessively polished.  The biggest
reason for the speed change is the rewritten stdio and
unicode-everything.  Hopefully this stuff can be improved in future
updates.  I don't think anyone WANTS cpython to be slower.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python for amd64 and mingw-w64

[David Cournapeau]

On Fri, Dec 19, 2008 at 3:30 PM, "Martin v. Löwis"  wrote:
>>  - Any extension requires the MS_WIN64 to be defined, but this symbol
>> is only defined for MS compiler (in PC/pyport.h).
>
> Why do you say that? It is only defined when _WIN64 is defined; this
> has nothing to do with a MS compiler.
>
>> Shouldn't it be
>> defined independantly of the compiler ?
>
> You mean, completely unconditional? Definitely not, it should only
> be defined when you are compiling for 64-bit mode.

I put a more detailed explanation of the problem with an example + a
patch on the bug tracker:

http://bugs.python.org/issue4709

This is the only problem on python side of things to make extensions
buildable on windows x64 (all the other problems I have encountered so
far to make numpy build with mingw-w64 are numpy's or mingw-w64).

David
--
http://mail.python.org/mailman/listinfo/python-list