Re: subprocess.Popen and thread module

[Chris Rebert]

> On Tue, Aug 9, 2011 at 11:38 PM, Danny Wong (dannwong)
>  wrote:
>> Hi All,
>>   I'm trying to execute some external commands from multiple database.
>> I'm using threads and subprocess.Popen ( from docs, all the popen*
>> functions are deprecated and I was told to use subprocess.Popen) to
>> execute the external commands in parallel, but the commands seems to
>> hang.
>
> What's your Popen() call look like?

On Tue, Aug 9, 2011 at 11:48 PM, Danny Wong (dannwong)
 wrote:
>    try:
>        cmd_output = subprocess.Popen(['scm', 'load', '--force', '-r', 
> nickname, '-d', directory, project], stdout=subprocess.PIPE, 
> stderr=subprocess.PIPE)
>        status = cmd_output.wait()

Er, did you read the warning about Popen.wait() in the docs? (emphasis added):
"""
Popen.wait()
Wait for child process to terminate. Set and return returncode attribute.
Warning: ***This will deadlock*** when using stdout=PIPE and/or
stderr=PIPE and the child process generates enough output to a pipe
such that it blocks waiting for the OS pipe buffer to accept more
data. Use communicate() to avoid that.
"""
– http://docs.python.org/library/subprocess.html#subprocess.Popen.wait

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

RE: subprocess.Popen and thread module

[Danny Wong (dannwong)]

I did read that portion of the doc, then I change it to communicate and it 
still hangs. So I reverted back to "wait" while launching one thread to see if 
I could isolate the problem, but it still hangs regardless of using "wait" or 
"communicate".

-Original Message-
From: ch...@rebertia.com [mailto:ch...@rebertia.com] On Behalf Of Chris Rebert
Sent: Tuesday, August 09, 2011 11:53 PM
To: Danny Wong (dannwong)
Cc: python-list@python.org
Subject: Re: subprocess.Popen and thread module

> On Tue, Aug 9, 2011 at 11:38 PM, Danny Wong (dannwong)
>  wrote:
>> Hi All,
>>   I'm trying to execute some external commands from multiple database.
>> I'm using threads and subprocess.Popen ( from docs, all the popen*
>> functions are deprecated and I was told to use subprocess.Popen) to
>> execute the external commands in parallel, but the commands seems to
>> hang.
>
> What's your Popen() call look like?

On Tue, Aug 9, 2011 at 11:48 PM, Danny Wong (dannwong)
 wrote:
>    try:
>        cmd_output = subprocess.Popen(['scm', 'load', '--force', '-r', 
> nickname, '-d', directory, project], stdout=subprocess.PIPE, 
> stderr=subprocess.PIPE)
>        status = cmd_output.wait()

Er, did you read the warning about Popen.wait() in the docs? (emphasis added):
"""
Popen.wait()
Wait for child process to terminate. Set and return returncode attribute.
Warning: ***This will deadlock*** when using stdout=PIPE and/or
stderr=PIPE and the child process generates enough output to a pipe
such that it blocks waiting for the OS pipe buffer to accept more
data. Use communicate() to avoid that.
"""
– http://docs.python.org/library/subprocess.html#subprocess.Popen.wait

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

Run clang static analyzer on Python 3.30a

[Seung Soo , Ha]

Hello,

I just ran the clang static analyzer on Python.

I'm very new to this, so please bear with me as a describe the exact steps I 
took.


1. hg clone of python
2. scan-build ./configure --with-pydebug
3. scan-build make -s -j4
4. scan-view /tmp/scan-build-2011-08-10-1/

It shows 6 bugs and the report page even has a 
friendly option to report the bug.

I'm just starting to learn C and I cannot judge whether they are worth 
reporting.

Should I?

I am aware of the issue tracker and how to use it. 
What I'm curious is what information I should provide, considering the fact
that my skills (for now) is limited to copy and paste.

What should I do next?


(my system Ubuntu 11.04  x86_64 on AMD Phenom II X4 955)

Thanks.

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

Re: subprocess.Popen and thread module

[Chris Rebert]

> From: Chris Rebert 
>> On Tue, Aug 9, 2011 at 11:38 PM, Danny Wong (dannwong)
>>  wrote:
>>> Hi All,
>>>   I'm trying to execute some external commands from multiple database.
>>> I'm using threads and subprocess.Popen ( from docs, all the popen*
>>> functions are deprecated and I was told to use subprocess.Popen) to
>>> execute the external commands in parallel, but the commands seems to
>>> hang.
>>
>> What's your Popen() call look like?
>
> On Tue, Aug 9, 2011 at 11:48 PM, Danny Wong (dannwong)
>  wrote:
>>    try:
>>        cmd_output = subprocess.Popen(['scm', 'load', '--force', '-r', 
>> nickname, '-d', directory, project], stdout=subprocess.PIPE, 
>> stderr=subprocess.PIPE)
>>        status = cmd_output.wait()
>
> Er, did you read the warning about Popen.wait() in the docs? (emphasis added):

On Tue, Aug 9, 2011 at 11:56 PM, Danny Wong (dannwong)
 wrote:
> I did read that portion of the doc, then I change it to communicate and it 
> still hangs. So I reverted back to "wait" while launching one thread to see 
> if I could isolate the problem, but it still hangs regardless of using "wait" 
> or "communicate".

Since you want to log the output to a file, have you tried:

logfile = open("path/to/file", 'r')
proc = subprocess.Popen(['scm', 'load', '--force', '-r', nickname,
'-d', directory, project], stdout=logfile, stderr=subprocess.STDOUT)
status = proc.wait()

or similar?

Cheers,
Chris
--
Damn Outlook/Exchange and its "On Behalf Of"!
http://rebertia.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: allow line break at operators

[Steven D'Aprano]

On Wed, 10 Aug 2011 04:05 pm Yingjie Lan wrote:

> :# the currently allowed way
> :x = (1+2+3+4+
> :1+2+3+4)
> :# note the parentheses
> :
> :I think this is sufficient.
> 
> That works, but not in the most natural way--the way people are customed
> to...why require a pair of parenthis when we can do without them? 

Because it is better to be explicit that the line is still open. An opening
parenthesis or bracket that hasn't been closed is an explicit sign that the
line is still open. An operator is not.


> Also, 
> the new way does not affect the old ways of doing things at all, it is
> fully backward compatible. So this just offers a new choice.

You say that as if having more choices is always good. It isn't. More
choices means more for people to learn, more complicated parser, more
options to consider, and more likelihood that errors will fail to raise
SyntaxError and instead go on to silently do the wrong thing. A new choice
should only be accepted when there is a clear and obvious benefit, not
merely because it will provide more choice.

Python is a programming language, not an ice cream shop.


>> Of course, the dot operator is also included, which may facilitate method
>> chaining:
>>
>> x = svg.append( 'circle' ).
>> r(2).cx(1).xy(1).
>> foreground('black').bkground('white')

If you are chaining six dots like that, you are in gross violation of the
Law Of Demeter. That is poor code, and should be discouraged, not
encouraged.


> 
> :Also, I dislike this for the dot operator especially, as it can
> :obscure whether a method call or a function call is taking place.
> 
> Again, this only offers a new choice, and does not force anybody to do it
> this way.

But it does force people to read it, because some people will use it, and so
others will have to suffer for their poor judgement.



-- 
Steven

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

Re: allow line break at operators

[Chris Angelico]

On Wed, Aug 10, 2011 at 9:32 AM, Steven D'Aprano
 wrote:
>>> Of course, the dot operator is also included, which may facilitate method
>>> chaining:
>>>
>>> x = svg.append( 'circle' ).
>>> r(2).cx(1).xy(1).
>>> foreground('black').bkground('white')
>
> If you are chaining six dots like that, you are in gross violation of the
> Law Of Demeter. That is poor code, and should be discouraged, not
> encouraged.

I would only accept that this is poor code IF there is a viable
alternative, such as:

x = svg.append(circle(r=2,cx=1,xy=1,foreground='black',bkground='white'))

This would, imho, be a more Pythonic way to do it. But if this isn't
available, and if the methods already return self, then I see nothing
wrong with chaining. It's a handy way of getting additional mileage
out of lambdas and list comps when writing one-liners. :)

(Cue long thread about whether or not one-liners are Pythonic.)

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

http://123maza.com/65/share858/

[ranganayaki rangs]

http://123maza.com/65/share858/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Restricted attribute writing

[Thomas Jollans]

On 07/08/11 17:35, John O'Hagan wrote:
> I'm looking for good ways to ensure that attributes are only writable such 
> that they retain the characteristics the class requires. 
> 
> My particular case is a class attribute which is initialised as a list of 
> lists of two integers, the first of which is a modulo remainder. I need to be 
> able to write to it like a normal list, but want to ensure it is only 
> possible to do so without changing that format. 
> 
> Below is a what I eventually came up with; a container class called 
> OrderElement for the inner lists, and subclass of list called Order for the 
> main attribute, which is a property of the main class, simplified below as 
> SeqSim.  It works, but seems like a hell of a lot of code for a simple idea. 
> I'm interested in ideas for simpler solutions, and general advice on how to 
> do this kind of thing in a straightforward way.  

What I think you're looking for is properties:

http://docs.python.org/py3k/library/functions.html#property

So: with a property, channel getting and setting through functions that
can check the value for validity.
Secondly, use tuples instead of lists where possible: they're not
mutable, which makes controlling their value a lot easier.
If your attribute is a list that users may append elements to, consider
adding an addelement(tpl) method to your class that checks the value
and appends it to the list.

Lastly, consider the option of not checking vigorously at all at that
point: If the value is invalid, it will raise an exception later, when
it is used. Depending on what you're doing, this might be all the
checking you need. If you're going to serialise the data, or if you want
to use the property setter to check user input directly, that's probably
not a strong option.

Thomas

> 
> 
> class OrderElement():
> """Container class which can only hold two integers
>the first of which is a modulo of the 'length' arg"""
> def __init__(self, lis, length):
> self.__data = [None, None]
> self.__length=length
> self[:] = lis
> 
> def __setitem__(self, index, item):
> if isinstance(index, slice):
> inds = range(*index.indices(2))
> for k, v in enumerate(item):
> self[inds[k]] = v
> elif isinstance(item, int):
> if index == 0:
> item %= self.__length
> self.__data[index] = item
> else:
> raise TypeError("OrderElement takes two integers")
> 
> def __getitem__(self, index):
> return self.__data[index]
> 
> 
> class Order(list):
> """Can only contain OrderElements"""
> def __init__(self, lis, length):
> self.__length = length
> self[:] = lis
> 
> def __setitem__(self, index, item):
> if isinstance(index, slice):
> item = [i if isinstance(i, OrderElement)
> else OrderElement(i, self.__length)
> for i in item]
> elif not isinstance(item, OrderElement):
> item = OrderElement(item, self.__length)   
> list.__setitem__(self, index, item)
> 
> def __getitem__(self, index):
> """Ensure slices are of the same class"""
> if isinstance(index, slice):
> return self.__class__(list.__getitem__(self, index),
> self.__length)
> return list.__getitem__(self, index)
> 
> 
> class SeqSim():
> """Just the relevant bits of the main class"""
> def __init__(self, lis, length):
> self.__order = Order(lis, length)
> self.length = length
> 
> @property
> def order(self):
> return self.__order
> 
> @order.setter
> def order(self, lis):
> if not isinstance(lis, Order):
> lis = Order(lis, self.length)
> self.__order = lis
> 

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

Re: allow line break at operators

[Dan Sommers]

On Wed, 10 Aug 2011 18:32:05 +1000, Steven D'Aprano wrote:

> Python is a programming language, not an ice cream shop.

+1 QOTW

How about a cheese shop?

In terms of easier to read, I find code easier to read when the operators 
are at the beginnings of the lines (PEP 8 notwithstanding):

x = (someobject.somemethod(object3, thing)
 + longfunctionname(object2)
 + otherfunction(value1, value2, value3))

I can see the "+" signs a lot easier there than at the end of some line, 
where it might be buried between two longer lines:

x = (someobject.somemethod(object3, thing) +
 longfunctionname(object2) + 
 otherfunction(value1, value2, value3))
-- 
Dan

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

Re: subprocess.Popen and thread module

[Thomas Rachel]

Am 10.08.2011 08:38 schrieb Danny Wong (dannwong):

Hi All,
I'm trying to execute some external commands from multiple database.
I'm using threads and subprocess.Popen ( from docs, all the popen*
functions are deprecated and I was told to use subprocess.Popen) to
execute the external commands in parallel, but the commands seems to
hang.
My question is:
Is subprocess.Popen thread safe?


Do you really need threads here? As you just run those external commands 
(as far as I understand), it might be enough to start the commands, hold 
their object, read them out (maybe part for part) and then wait().



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

Re: allow line break at operators

[Chris Angelico]

On Wed, Aug 10, 2011 at 10:56 AM, Dan Sommers  wrote:
> In terms of easier to read, I find code easier to read when the operators
> are at the beginnings of the lines (PEP 8 notwithstanding):
>
>    x = (someobject.somemethod(object3, thing)
>         + longfunctionname(object2)
>         + otherfunction(value1, value2, value3))
>

Without the parentheses, this is legal but (probably) useless; it
applies the unary + operator to the return value of those functions.
Putting the + at the end of the previous line at least prevents that,
since most unary operators bind to the operand on the right; but
there's still the potential for ambiguity.

When line breaks are significant, they cannot be randomly inserted
inside expressions.

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

Re: allow line break at operators

[TheSaint]

Yingjie Lan wrote:

> #the new way
> x = 1+2+3+4+ #line continues as it is clearly unfinished
> 
> 1+2+3+4
> 
Genrally I prefer this way.
> Of course, the dot operator is also included, which may facilitate method
> chaining:
> 
> x = svg.append( 'circle' ).

Dot-ended is to tiny thing that might cause oversights. *If* it'll be used 
as a secondary option I think it doesn't matter, otherwise *if* use as a 
compulsory writing mode I'd say it is pretty mistake prone.


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

Re: How to solve this problem

[Chris Angelico]

On Tue, Aug 9, 2011 at 12:10 PM, Johny  wrote:
> I have a client that  is a part of a local network.This client has a
> local address( not public).Is there a way how I can connect to this
> client from outside world?
> What software must I install so that I can connect and control that
> client from outside?

Presumably you are using NAT (Network Address Translation). You'll
need to arrange for a port (or a set of ports) to be forwarded to that
computer, which is done by configuring your NAT router. In a simple
home network, this usually means logging in using the router's home
page, such as http://192.168.0.1/ or http://192.168.1.1/ (it'll be the
same as your default gateway); otherwise, talk to your network admin
about it.

The port or ports that you need to forward will depend on what you
mean by "connect and control". For SSH, that's port 22; for VNC, port
5900. Other services are on other ports.

By the way, this is a networking question, not a Python one.

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

How to solve this problem

[jana1972]

I have a client that  is a part of a local network.This client has a local 
address( not public).Is 
there a way how I can connect to this client from outside world?
What software must I install so that I can connect and control that client from 
outside?

Thanks

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

String concatenation - which is the fastest way ?

[przemolicc]

Hello,

I'd like to write a python (2.6/2.7) script which connects to database, fetches
hundreds of thousands of rows, concat them (basically: create XML)
and then put the result into another table. Do I have any choice
regarding string concatenation in Python from the performance point of view ?
Since the number of rows is big I'd like to use the fastest possible library
(if there is any choice). Can you recommend me something ?

Regards
Przemyslaw Bak (przemol)




















































Znajdz samochod idealny dla siebie!
Szukaj >> http://linkint.pl/f2a0a
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: allow line break at operators

[Duncan Booth]

Chris Angelico  wrote:

> On Wed, Aug 10, 2011 at 10:56 AM, Dan Sommers 
> wrote: 
>> In terms of easier to read, I find code easier to read when the
>> operators are at the beginnings of the lines (PEP 8 notwithstanding):
>>
>>    x = (someobject.somemethod(object3, thing)
>>         + longfunctionname(object2)
>>         + otherfunction(value1, value2, value3))
>>
> 
> Without the parentheses, this is legal but (probably) useless; it
> applies the unary + operator to the return value of those functions.

No, in some other languages it might be legal, but this is Python.
without the parentheses it is a syntax error.


-- 
Duncan Booth http://kupuguy.blogspot.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: String concatenation - which is the fastest way ?

[Chris Angelico]

On Wed, Aug 10, 2011 at 12:17 PM,   wrote:
> Hello,
>
> I'd like to write a python (2.6/2.7) script which connects to database, 
> fetches
> hundreds of thousands of rows, concat them (basically: create XML)
> and then put the result into another table. Do I have any choice
> regarding string concatenation in Python from the performance point of view ?
> Since the number of rows is big I'd like to use the fastest possible library
> (if there is any choice). Can you recommend me something ?

First off, I have no idea why you would want to create an XML dump of
hundreds of thousands of rows, only to store it in another table.
However, if that is your intention, list joining is about as efficient
as you're going to get in Python:

lst=["asdf","qwer","zxcv"] # feel free to add 399,997 more list entries
xml=""+"".join(lst)+""

This sets xml to 'asdfqwerzxcv' which
may or may not be what you're after.

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

Re: allow line break at operators

[Chris Angelico]

On Wed, Aug 10, 2011 at 1:25 PM, Duncan Booth
 wrote:
> Chris Angelico  wrote:
>
>> On Wed, Aug 10, 2011 at 10:56 AM, Dan Sommers 
>> wrote:
>>> In terms of easier to read, I find code easier to read when the
>>> operators are at the beginnings of the lines (PEP 8 notwithstanding):
>>>
>>>    x = (someobject.somemethod(object3, thing)
>>>         + longfunctionname(object2)
>>>         + otherfunction(value1, value2, value3))
>>>
>>
>> Without the parentheses, this is legal but (probably) useless; it
>> applies the unary + operator to the return value of those functions.
>
> No, in some other languages it might be legal, but this is Python.
> without the parentheses it is a syntax error.

It would be parsed as three separate statements. The only reason it
would be a syntax error would be because of the indentation, which is
not what I'd call reliable; it happens to catch this case, because
assignment doesn't allow subsequent lines to be indented, but nothing
forces continuation lines to be indented.

x = (5
+4)

x = 5
+4

What we have is a strangeness that can arise when a programmer ignores
something that is often insignificant; spare parentheses usually don't
matter.

Another potential danger is the similarity with tuple creation:

x = (someobject.somemethod(object3, thing)
     + longfunctionname(object2)
     + otherfunction(value1, value2, value3),)

This is a tuple with one element. Not too bad with the + operator, but
imagine if everything's done with method chaining on . which results
in the , being nearly indistinguishable. Not an insurmountable
problem, but a potential risk.

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

gtk STOCK_SAVE text in another language

[Peter Irbizon]

hello, I have slovak win but I would like to have english captions on pygtk
STOCK_SAVE buttons. How can I set this? thanks
-- 
http://mail.python.org/mailman/listinfo/python-list

I need help/information on Freeze.py

[mike turner]

Hello all,


How do you use freeze.py to freeze an application? I have an application
built with pylons and I want to make it into a portable executable, is that
possible? Thanks for the help.


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

Re: allow line break at operators

[Yingjie Lan]

> On Wed, Aug 10, 2011 at 10:56 AM, Dan Sommers 

> wrote: 
>> In terms of easier to read, I find code easier to read when the
>> operators are at the beginnings of the lines (PEP 8 notwithstanding):
>>
>>    x = (someobject.somemethod(object3, thing)
>>         + longfunctionname(object2)
>>         + otherfunction(value1, value2, value3))
>>
> 
> Without the parentheses, this is legal but (probably) useless; it
> applies the unary + operator to the return value of those functions.

:No, in some other languages it might be legal, but this is Python.
:without the parentheses it is a syntax error.

This discussion leads me to this question:

Is it possible for python to allow free splitting of single-line statements
without the backslashes, if we impose that expressions can only be split
when it is not yet a finished expression? Note: splitting before closing 
parenthis, brace, or bracket can be viewed as special case of this 
more general rule.


Yingjie

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

Re: String concatenation - which is the fastest way ?

[przemolicc]

On Wed, Aug 10, 2011 at 01:32:06PM +0100, Chris Angelico wrote:
> On Wed, Aug 10, 2011 at 12:17 PM,   wrote:
> > Hello,
> >
> > I'd like to write a python (2.6/2.7) script which connects to database, 
> > fetches
> > hundreds of thousands of rows, concat them (basically: create XML)
> > and then put the result into another table. Do I have any choice
> > regarding string concatenation in Python from the performance point of view 
> > ?
> > Since the number of rows is big I'd like to use the fastest possible library
> > (if there is any choice). Can you recommend me something ?
> 
> First off, I have no idea why you would want to create an XML dump of
> hundreds of thousands of rows, only to store it in another table.
> However, if that is your intention, list joining is about as efficient
> as you're going to get in Python:
> 
> lst=["asdf","qwer","zxcv"] # feel free to add 399,997 more list entries
> xml=""+"".join(lst)+""
> 
> This sets xml to 'asdfqwerzxcv' which
> may or may not be what you're after.

Chris,

since this process (XML building) is running now inside database (using native 
SQL commands)
and is one-thread task it is quite slow. What I wanted to do is to spawn 
several python subprocesses in parallel which
will concat subset of the whole table (and then merge all of them at the end).
Basically:
- fetch all rows from the database (up to 1 million): what is recommended data 
type ?
- spawn X python processes each one:
- concat its own subset
- merge the result from all the subprocesses

This task is running on a server which has many but slow cores and I am trying 
to divide this task
into many subtasks.

Regards
Przemyslaw Bak (przemol)



















































Doladuj telefon przez Internet!
Sprawdz >> http://linkint.pl/f2a06
-- 
http://mail.python.org/mailman/listinfo/python-list

SocketServer expceion after upgrading to 2.7

[Laszlo Nagy]

Exception happened during processing of request from ('80.99.165.122', 
56069)

Traceback (most recent call last):
  File "/usr/local/lib/python2.7/SocketServer.py", line 284, in 
_handle_request_noblock

self.process_request(request, client_address)
  File "/usr/local/lib/python2.7/SocketServer.py", line 311, in 
process_request

self.shutdown_request(request)
  File "/usr/local/lib/python2.7/SocketServer.py", line 459, in 
shutdown_request

request.shutdown(socket.SHUT_WR)
TypeError: shutdown() takes exactly 0 arguments (1 given)


I get this error with a program, after upgrading to python 2.7. I'm 
using a program that is based on SocketServer and SimpleXMLRPCDispatcher.


Any idea how to fix this?

Thanks,

   Laszlo


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

Python-URL! - weekly Python news and links (Aug 10)

[Cameron Laird]

QOTW: "If an elegant solution doesn't occur to me right away, then I
first
compose the most obvious solution I can think of. Finally, I refactor
it
until elegance is either achieved or imagined." - Neil Cerutti,
2011-07-28


   What is the real purpose of __all__?
   http://old.nabble.com/__all__-td32227593.html

   __set__ does not appear to work for class attributes:
   http://groups.google.com/group/comp.lang.python/t/72a346299a7eacf5/

   Talking of class attributes: how to set up a docstring for them?
   http://old.nabble.com/Docstrings-and-class-Attributes-td32218039.html

   Using zip to separate a list of pairs into two lists:
   http://groups.google.com/group/comp.lang.python/t/98008a2c63b002fa/

   Detecting object differences in order to propagate the changes over
   a network:
   http://old.nabble.com/Object-Diffs-ts32221405.html

   modules, classes, and functions: all appear to be different ways to
   execute a block of code; similarities and differences
http://groups.google.com/group/comp.lang.python/t/79bc8b7d5267338a/

   Replace all references to one object with another, is it possible?
http://groups.google.com/group/comp.lang.python/t/32b67545254bdf37/

   Ensure certain attributes, even if writable and modifiable,
maintain
   certain invariants:
   http://groups.google.com/group/comp.lang.python/t/d23a48c858b2cb75/

Everything Python-related you want is probably one or two clicks away
in
these pages:

   Python.org's Python Language Website is the traditional
   center of Pythonia
   http://www.python.org
   Notice especially the master FAQ
   http://www.python.org/doc/FAQ.html

   Just beginning with Python?  This page is a great place to start:
   http://wiki.python.org/moin/BeginnersGuide/Programmers

   Planet Python:  you want to visit there:
   http://planet.python.org
   But don't confuse it with Planet SciPy:
   http://planet.scipy.org
   And don't confuse *that* with SciPyTip, a high-quality daily (!)
tip
   for the numerically-inclined:
   http://twitter.com/SciPyTip

   Python Insider is the official blog of the Python core development
   team:
   
http://pyfound.blogspot.com/2011/03/python-dev-launches-python-insider-blog.html

   The Python Software Foundation (PSF) has replaced the Python
   Consortium as an independent nexus of activity.  It has official
   responsibility for Python's development and maintenance.
   http://www.python.org/psf/
   Among the ways you can support PSF is with a donation.
   http://www.python.org/psf/donations/
   Keep up with the PSF at "Python Software Foundation News":
   http://pyfound.blogspot.com

   The Python Papers aims to publish "the efforts of Python
enthusiasts":
   http://pythonpapers.org/

   Doug Hellman's "Module of the week" is essential reading:
   http://www.doughellmann.com/PyMOTW/

   comp.lang.python.announce announces new Python software.  Be
   sure to scan this newsgroup weekly.
   http://groups.google.com/group/comp.lang.python.announce/topics

   Python411 indexes "podcasts ... to help people learn Python ..."
   Updates appear more-than-weekly:
   http://www.awaretek.com/python/index.html

   The Python Package Index catalogues packages.
   http://www.python.org/pypi/

   Much of Python's real work takes place on Special-Interest Group
   mailing lists
   http://www.python.org/sigs/

   Python Success Stories--from air-traffic control to on-line
   match-making--can inspire you or decision-makers to whom you're
   subject with a vision of what the language makes practical.
   http://www.pythonology.com/success

   The Summary of Python Tracker Issues is an automatically generated
   report summarizing new bugs, closed ones, and patch submissions.
   
http://search.gmane.org/?author=status%40bugs.python.org&group=gmane.comp.python.devel&sort=date

   nullege is an interesting search Web application, with the
intelligence
   to distinguish between Python code and comments.  It provides what
   appear to be relevant results, and demands neither Java nor CSS be
   enabled:
   http://www.nullege.com

   Although unmaintained since 2002, the Cetus collection of Python
   hyperlinks retains a few gems.
   http://www.cetus-links.org/oo_python.html

   The Cookbook is a collaborative effort to capture useful and
   interesting recipes:
   http://code.activestate.com/recipes/langs/python/

   Many Python conferences around the world are in preparation.
   Watch this space for links to them.

   Among several Python-oriented RSS/RDF feeds available, see:
   http://www.python.org/channews.rdf
   For more, see:
   http://www.syndic8.com/feedlist.php?ShowMatch=python&ShowStatus=all
   The old Python "To-Do List" now lives principally in a
   SourceForge reincarnation.
   http://sourceforge.net/tracker/?atid=355470&group_id=54

Python-URL! - weekly Python news and links (Aug 10)

[Cameron Laird]

QOTW: "If an elegant solution doesn't occur to me right away, then I
first
compose the most obvious solution I can think of. Finally, I refactor
it
until elegance is either achieved or imagined." - Neil Cerutti,
2011-07-28


   What is the real purpose of __all__?
   http://old.nabble.com/__all__-td32227593.html

   __set__ does not appear to work for class attributes:
   http://groups.google.com/group/comp.lang.python/t/72a346299a7eacf5/

   Talking of class attributes: how to set up a docstring for them?
   http://old.nabble.com/Docstrings-and-class-Attributes-td32218039.html

   Using zip to separate a list of pairs into two lists:
   http://groups.google.com/group/comp.lang.python/t/98008a2c63b002fa/

   Detecting object differences in order to propagate the changes over
   a network:
   http://old.nabble.com/Object-Diffs-ts32221405.html

   modules, classes, and functions: all appear to be different ways to
   execute a block of code; similarities and differences
http://groups.google.com/group/comp.lang.python/t/79bc8b7d5267338a/

   Replace all references to one object with another, is it possible?
http://groups.google.com/group/comp.lang.python/t/32b67545254bdf37/

   Ensure certain attributes, even if writable and modifiable,
maintain
   certain invariants:
   http://groups.google.com/group/comp.lang.python/t/d23a48c858b2cb75/

Everything Python-related you want is probably one or two clicks away
in
these pages:

   Python.org's Python Language Website is the traditional
   center of Pythonia
   http://www.python.org
   Notice especially the master FAQ
   http://www.python.org/doc/FAQ.html

   Just beginning with Python?  This page is a great place to start:
   http://wiki.python.org/moin/BeginnersGuide/Programmers

   Planet Python:  you want to visit there:
   http://planet.python.org
   But don't confuse it with Planet SciPy:
   http://planet.scipy.org
   And don't confuse *that* with SciPyTip, a high-quality daily (!)
tip
   for the numerically-inclined:
   http://twitter.com/SciPyTip

   Python Insider is the official blog of the Python core development
   team:
   
http://pyfound.blogspot.com/2011/03/python-dev-launches-python-insider-blog.html

   The Python Software Foundation (PSF) has replaced the Python
   Consortium as an independent nexus of activity.  It has official
   responsibility for Python's development and maintenance.
   http://www.python.org/psf/
   Among the ways you can support PSF is with a donation.
   http://www.python.org/psf/donations/
   Keep up with the PSF at "Python Software Foundation News":
   http://pyfound.blogspot.com

   The Python Papers aims to publish "the efforts of Python
enthusiasts":
   http://pythonpapers.org/

   Doug Hellman's "Module of the week" is essential reading:
   http://www.doughellmann.com/PyMOTW/

   comp.lang.python.announce announces new Python software.  Be
   sure to scan this newsgroup weekly.
   http://groups.google.com/group/comp.lang.python.announce/topics

   Python411 indexes "podcasts ... to help people learn Python ..."
   Updates appear more-than-weekly:
   http://www.awaretek.com/python/index.html

   The Python Package Index catalogues packages.
   http://www.python.org/pypi/

   Much of Python's real work takes place on Special-Interest Group
   mailing lists
   http://www.python.org/sigs/

   Python Success Stories--from air-traffic control to on-line
   match-making--can inspire you or decision-makers to whom you're
   subject with a vision of what the language makes practical.
   http://www.pythonology.com/success

   The Summary of Python Tracker Issues is an automatically generated
   report summarizing new bugs, closed ones, and patch submissions.
   
http://search.gmane.org/?author=status%40bugs.python.org&group=gmane.comp.python.devel&sort=date

   nullege is an interesting search Web application, with the
intelligence
   to distinguish between Python code and comments.  It provides what
   appear to be relevant results, and demands neither Java nor CSS be
   enabled:
   http://www.nullege.com

   Although unmaintained since 2002, the Cetus collection of Python
   hyperlinks retains a few gems.
   http://www.cetus-links.org/oo_python.html

   The Cookbook is a collaborative effort to capture useful and
   interesting recipes:
   http://code.activestate.com/recipes/langs/python/

   Many Python conferences around the world are in preparation.
   Watch this space for links to them.

   Among several Python-oriented RSS/RDF feeds available, see:
   http://www.python.org/channews.rdf
   For more, see:
   http://www.syndic8.com/feedlist.php?ShowMatch=python&ShowStatus=all
   The old Python "To-Do List" now lives principally in a
   SourceForge reincarnation.
   http://sourceforge.net/tracker/?atid=355470&group_id=54

problem with GTK language

[Peter Irbizon]

Hello,
I have strange problem with gtk language in pygtk. When I run .py file it
shows all gtk labels in my default windows language (slovak). But when I
compile it with py2exe and run exe file all labels are in english. Why this
happens? How can I define on program startup which language to use? I would
like to choose between english and slovak. I tryed to set locals in my
application but no luck. What am I doing wrong?

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

Re: Segmentation Fault on exit

[ron]

On Aug 6, 6:35 am, Vipul Raheja  wrote:
> Hi,
>
> I have wrapped a library from C++ to Python using SWIG. But when I
> import it in Python, I am able to work fine with it, but it gives a
> segmentation fault while exiting. Following is the log:
>
> vipul@vipul-laptop:~/ossim-svn/src/pyossim/swig$ python
> Python 2.6.6 (r266:84292, Sep 15 2010, 15:52:39)
> [GCC 4.4.5] on linux2
> Type "help", "copyright", "credits" or "license" for more information.>>> 
> import pyossim
>
> * Do some stuff *
> >>> exit()
>
> Segmentation fault
> vipul@vipul-laptop:~/ossim-svn/src/pyossim/swig$
>
> Kindly help.
>
> Thanks and Regards,
> Vipul Raheja

Check out Valgrind.  It's easy to set up, runs like gdb, but keeps
track and flags any offending memory use at the c level. Then just
need to find the calling python code.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: __set__ method is not called for class attribute access

[Fuzzyman]

On Aug 5, 12:29 pm, Ryan  wrote:
> In the context of descriptors, the __set__ method is not called for
> class attribute access. __set__ is only
> called to set the attribute on an instance instance of the owner class
> to a new value, value. WHY?

It's an unfortunate asymmetry in the descriptor protocol. You can
write "class descriptors" with behaviour on get, but not on set.

As others point out, metaclasses are an ugly way round this
(particularly given that *basically* a class can only have one
metaclass - so if you're inheriting from a class that already has a
custom metaclass you can't use this technique).

Michael Foord
--
http://voidspace.org.uk/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: String concatenation - which is the fastest way ?

[Chris Angelico]

On Wed, Aug 10, 2011 at 2:31 PM,   wrote:
> - fetch all rows from the database (up to 1 million): what is recommended 
> data type ?
> - spawn X python processes each one:
>    - concat its own subset
> - merge the result from all the subprocesses
>

What you're writing is, fundamentally, glue between your SQL engine
and your SQL engine. Look up what you get from your query and work
with that. Which SQL library are you suing?

Python may and may not be the best tool for this job.

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

Re: String concatenation - which is the fastest way ?

[Chris Angelico]

On Wed, Aug 10, 2011 at 3:38 PM, Chris Angelico  wrote:
> Which SQL library are you suing?

And this is why I should proof-read BEFORE, not AFTER, sending.

Which SQL library are you *using*?

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

Re: String concatenation - which is the fastest way ?

[Steven D'Aprano]

przemol...@poczta.fm wrote:

> Hello,
> 
> I'd like to write a python (2.6/2.7) script which connects to database,
> fetches hundreds of thousands of rows, concat them (basically: create XML)
> and then put the result into another table. Do I have any choice
> regarding string concatenation in Python from the performance point of
> view ? Since the number of rows is big I'd like to use the fastest
> possible library (if there is any choice). Can you recommend me something
> ?

For fast string concatenation, you should use the string.join method:

substrings = ['a', 'bb', 'ccc', '']
body = ''.join(substrings)

Using string addition in a loop, like this:

# Don't do this!
body = ''
for sub in substrings:
body += sub

risks being *extremely* slow for large numbers of substrings. (To be
technical, string addition can O(N**2), while ''.join is O(N).) This
depends on many factors, including the operating system's memory
management, and the Python version and implementation, so repeated addition
may be fast on one machine and slow on another. Better to always use join,
which is consistently fast.

You should limit string addition to small numbers of substrings:

result = head + body + tail  # This is okay.


-- 
Steven

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

Re: allow line break at operators

[Steven D'Aprano]

Chris Angelico wrote:

> On Wed, Aug 10, 2011 at 10:56 AM, Dan Sommers 
> wrote:
>> In terms of easier to read, I find code easier to read when the operators
>> are at the beginnings of the lines (PEP 8 notwithstanding):
>>
>> x = (someobject.somemethod(object3, thing)
>> + longfunctionname(object2)
>> + otherfunction(value1, value2, value3))
>>
> 
> Without the parentheses, this is legal but (probably) useless; it
> applies the unary + operator to the return value of those functions.
> Putting the + at the end of the previous line at least prevents that,
> since most unary operators bind to the operand on the right;

Not so:

>>> x = (42 + -
... 100)
>>>
>>> x
-58



-- 
Steven

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

Re: __set__ method is not called for class attribute access

[Fuzzyman]

On Aug 5, 1:16 pm, Duncan Booth  wrote:
> Ryan  wrote:
> > In the context of descriptors, the __set__ method is not called for
> > class attribute access. __set__ is only
> > called to set the attribute on an instance instance of the owner class
> > to a new value, value. WHY? Is there some other mechanism for
> > accomplishing this outcome. This subtle difference from __get__cost me
> > some time to track down. Might think about pointing that out the
> > documentation.
>
> > class RevealAccess(object):
> >     """A data descriptor that sets and returns values
> >        normally and prints a message logging their access.
> >     """
>
> >     def __init__(self, initval=None, name='var'):
> >         self.val = initval
> >         self.name = name
>
> >     def __get__(self, obj, objtype):
> >         print 'Retrieving', self.name
> >         return self.val
>
> >     def __set__(self, obj, val):
> >         print 'Updating' , self.name
> >         self.val = val
>
> > class MyClass(object):
> >     x = RevealAccess(10, 'var "x"')
> >     y = 5
>
> > print MyClass.x
> > MyClass.x = 20
> > print MyClass.x
> > MyClass.x = 30
> > print MyClass.x
>
> > Retrieving var "x"
> > 10
> > 20
> > 30
>
> > I am at a lost on how to intercept class attribute sets. Can anyone
> > help :-/
>
> The descriptor protocol only works when a value is being accessed or set
> on an instance and there is no instance attribute of that name so the
> value is fetched from the underlying class.
>

That's not true. Properties, for example, can be got or set even when
they shadow an instance attribute. You're (probably) thinking of
__getattr__ which isn't invoked when an instance attribute exists.

Also, the descriptor protocol *is* invoked for getting an attribute
from a class - but not when setting a class attribute. An unfortunate
asymmetry. It just wasn't considered as a use case when the descriptor
protocol was implemented.

Michael
--
http://voidspace.org.uk/

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

Re: allow line break at operators

[Steven D'Aprano]

Dan Sommers wrote:

> In terms of easier to read, I find code easier to read when the operators
> are at the beginnings of the lines (PEP 8 notwithstanding):
> 
> x = (someobject.somemethod(object3, thing)
>  + longfunctionname(object2)
>  + otherfunction(value1, value2, value3))

Agreed.


-- 
Steven

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

Re: allow line break at operators

[Chris Angelico]

On Wed, Aug 10, 2011 at 1:58 PM, Yingjie Lan  wrote:
> Is it possible for python to allow free splitting of single-line statements
> without the backslashes, if we impose that expressions can only be split
> when it is not yet a finished expression?

The trouble is that in a lot of cases, the next statement after an
unfinished expression could conceivably be a continuation of it. If
this were permitted, it would have to also require that the
continuation lines be indented, to avoid the problem described above.
It'd still have the potential to mis-diagnose errors, though.

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

Re: how to dynamically generate __name__ for an object?

[Fuzzyman]

On Aug 7, 4:06 am, Eric Snow  wrote:
> Thought I knew how to provide a dynamic __name__ on instances of a
> class.  My first try was to use a non-data descriptor:
>
> # module base.py
>
> class _NameProxy(object):
>     def __init__(self, oldname):
>         self.oldname = oldname
>     def __get__(self, obj, cls):
>         if obj is None:
>             return self.oldname
>         if "__name__" not in obj.__dict__:
>             return str(obj.__context__)
>         return obj.__name__
>
> class _BaseMeta(type):
>     def __init__(cls, name, bases, namespace):
>         cls.__name__ = _NameProxy(name)
>
> class Base(object):
>     __metaclass__ = _BaseMeta
>
> $ python _base.py
> Traceback (most recent call last):
>   ...
>   File "/usr/local/lib/python2.4/site-packages/base.py", line xx, in __init__
>     cls.__name__ = _NameProxy(name)
> TypeError: Error when calling the metaclass bases
>     can only assign string to Base.__name__, not '_NameProxy'
>
> Needless to say I was surprised.  After looking in typeobject.c, I
> believe that __name__ must be a string where classes are concerned[1].
>  So if I want all my instances to have a __name__ attribute, and for
> it to be dynamically provided if it isn't set on the instance, what
> are my options?  Or maybe I did something wrong and it should work as
> I expected?
>

__name__ can be a descriptor, so you just need to write a descriptor
that can be fetched from classes as well as instances.

Here's an example with a property (instance only):

>>> class Foo(object):
...   @property
...   def __name__(self):
... return 'bar'
...
>>> Foo().__name__
'bar'

Michael
--
http://voidspace.org.uk/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: allow line break at operators

[Chris Angelico]

On Wed, Aug 10, 2011 at 3:37 PM, Steven D'Aprano
 wrote:
>> Without the parentheses, this is legal but (probably) useless; it
>> applies the unary + operator to the return value of those functions.
>> Putting the + at the end of the previous line at least prevents that,
>> since most unary operators bind to the operand on the right;
>
> Not so:
>
 x = (42 + -
> ...     100)

 x
> -58

Your unary - is binding to the operand to its right, in this case the
100. (I think I have left and right correct; being in theatre has a
tendency to make you forget which is which.) Your + is binary,
operating on 42 and the result of applying unary - to 100, which is
-100.

My point about binding can be illustrated by inventing an operator @.
Let's say that a@b is the atan2 of a and b, and x@ is x factorial (I
can't imagine what deranged mind would do something like this, apart
from my own).

y = 5 @ # 120, as per factorial
x = 5 @ 2   # 1.19 or so, as per atan2
foo(123) # Calls foo() and discards its return value
z = 5 @
foo(123)

Is that last example one statement or two?

But this situation shouldn't ever occur in Python, because all its
unary operators (not, -, +, ~) bind to the operand to their right (I
don't think there's any I've missed, are there?). It does mean,
however, that a leading operator is not unambiguous. Without the
surrounding parentheses and/or otherwise-unexpected indentation, an
expression beginning with a + could conceivably be applying the unary
plus operator to the rest of the expression, rather than implying that
it's continuing the previous line.

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

Re: allow line break at operators

[Ian Kelly]

On Wed, Aug 10, 2011 at 8:37 AM, Steven D'Aprano
 wrote:
>> Without the parentheses, this is legal but (probably) useless; it
>> applies the unary + operator to the return value of those functions.
>> Putting the + at the end of the previous line at least prevents that,
>> since most unary operators bind to the operand on the right;
>
> Not so:
>
 x = (42 + -
> ...     100)

 x
> -58

That is still binding to the operand on the "right" (i.e., the
sequentially later).  And it still does not cause the problem that
Chris was talking about, since without the parentheses that would be a
syntax error.  So I guess I'm not certain what exactly it is that
you're trying to demonstrate here.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: how to dynamically generate __name__ for an object?

[Ian Kelly]

On Wed, Aug 10, 2011 at 8:48 AM, Fuzzyman  wrote:
> __name__ can be a descriptor, so you just need to write a descriptor
> that can be fetched from classes as well as instances.
>
> Here's an example with a property (instance only):
>
 class Foo(object):
> ...   @property
> ...   def __name__(self):
> ...     return 'bar'
> ...
 Foo().__name__
> 'bar'

But:

>>> Foo.__name__
'Foo'
>>> repr(Foo())
'<__main__.Foo object at 0x00CAFFD0>'
>>> Foo.__dict__['__name__']


It seems that Foo.__name__ and Foo.__dict__['__name__'] are not the
same thing, and Python itself only uses the former.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: __set__ method is not called for class attribute access

[Duncan Booth]

Fuzzyman  wrote:

>> The descriptor protocol only works when a value is being accessed or set
>> on an instance and there is no instance attribute of that name so the
>> value is fetched from the underlying class.
>>
> 
> That's not true. Properties, for example, can be got or set even when
> they shadow an instance attribute. You're (probably) thinking of
> __getattr__ which isn't invoked when an instance attribute exists.

Yes, Peter Otten already corrected me on that point last Friday and I 
posted thanking him on Sunday.


-- 
Duncan Booth http://kupuguy.blogspot.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: allow line break at operators

[Yingjie Lan]

>> In terms of easier to read, I find code easier to read when the

>> operators are at the beginnings of the lines (PEP 8 notwithstanding):
>>
>>    x = (someobject.somemethod(object3, thing)
>>         + longfunctionname(object2)
>>         + otherfunction(value1, value2, value3))
>>
> 
> Without the parentheses, this is legal but (probably) useless; it
> applies the unary + operator to the return value of those functions.

If ';' are employed (required), truely free line-splitting should be OK, 
the operators may appear at the beginnings of the lines as you wish.

Yingjie

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

Re: allow line break at operators

[Chris Angelico]

On Wed, Aug 10, 2011 at 2:19 PM, Yingjie Lan  wrote:
> If ';' are employed (required), truely free line-splitting should be OK,
> the operators may appear at the beginnings of the lines as you wish.
>

And if we require {} then truly free indentation should be OK too! But
it wouldn't be Python any more.

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

Re: Docstrings and class Attributes

[John Pinner]

On Aug 9, 1:36 am, Ben Finney  wrote:
> Ethan Furman  writes:
> > So if property docstrings are so hard to get to, what's the point in
> > having them?
>
> Why would you expect there be a special point to them?
>
> Men, like all primates of any sex, have nipples.
>
> Properties, like any function in Python, have docstrings.

So are you saying that men's nipples are pointless?

You could be correct, except in cold weather maybe.

John
--

>
> They're an accident of the history that led to their implementation, and
> of the pre-existing parts that they're built from. There doesn't need to
> be a point to them (though they might be useful for reasons incidental
> for the reasons they exist).
>
> --
>  \        “I filled my humidifier with wax. Now my room is all shiny.” |
>   `\                                                    —Steven Wright |
> _o__)                                                                  |
> Ben Finney

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

Re: String concatenation - which is the fastest way ?

[Stefan Behnel]

przemol...@poczta.fm, 10.08.2011 15:31:

On Wed, Aug 10, 2011 at 01:32:06PM +0100, Chris Angelico wrote:

On Wed, Aug 10, 2011 at 12:17 PM,  wrote:

I'd like to write a python (2.6/2.7) script which connects to database, fetches
hundreds of thousands of rows, concat them (basically: create XML)
and then put the result into another table. Do I have any choice
regarding string concatenation in Python from the performance point of view ?
Since the number of rows is big I'd like to use the fastest possible library
(if there is any choice). Can you recommend me something ?


First off, I have no idea why you would want to create an XML dump of
hundreds of thousands of rows, only to store it in another table.
However, if that is your intention, list joining is about as efficient
as you're going to get in Python:

lst=["asdf","qwer","zxcv"] # feel free to add 399,997 more list entries
xml=""+"".join(lst)+""

This sets xml to 'asdfqwerzxcv' which
may or may not be what you're after.


since this process (XML building) is running now inside database (using native 
SQL commands)
and is one-thread task it is quite slow. What I wanted to do is to spawn 
several python subprocesses in parallel which
will concat subset of the whole table (and then merge all of them at the end).
Basically:
- fetch all rows from the database (up to 1 million): what is recommended data 
type ?
- spawn X python processes each one:
 - concat its own subset
- merge the result from all the subprocesses

This task is running on a server which has many but slow cores and I am trying 
to divide this task
into many subtasks.


Makes sense to me. Note that the really good DBMSes (namely, PostgreSQL) 
come with built-in Python support.


You still didn't provide enough information to make me understand why you 
need XML in between one database and another (or the same?), but if you go 
that route, you can just read data through multiple connections in multiple 
threads (or processes), have each build up one (or more) XML entries, and 
then push those into a queue. Then another thread (or more than one) can 
read from that queue and write the XML items into a file (or another 
database) as they come in.


If your data has a considerable size, I wouldn't use string concatenation 
or joining at all (note that it requires 2x the memory during 
concatenation), but rather write it into a file, or even just process the 
data on the fly, i.e. write it back into the target table right away. 
Reading a file back in after the fact is much more resource friendly than 
keeping huge amounts of data in memory. And disk speed is usually not a 
problem when streaming data from disk into a database.


It may also be worth considering to write out literal SQL insert statements 
instead of XML. Most databases have a decent bulk upload tool.


Stefan

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

Re: __set__ method is not called for class attribute access

[Eric Snow]

On Wed, Aug 10, 2011 at 8:33 AM, Fuzzyman  wrote:
> On Aug 5, 12:29 pm, Ryan  wrote:
>> In the context of descriptors, the __set__ method is not called for
>> class attribute access. __set__ is only
>> called to set the attribute on an instance instance of the owner class
>> to a new value, value. WHY?
>
> It's an unfortunate asymmetry in the descriptor protocol. You can
> write "class descriptors" with behaviour on get, but not on set.
>
> As others point out, metaclasses are an ugly way round this
> (particularly given that *basically* a class can only have one
> metaclass - so if you're inheriting from a class that already has a
> custom metaclass you can't use this technique).

Keep in mind that you can still do something like this:

class XMeta(Base.__class__):
"Customize here"

class X(Base, metaclass=XMeta):
"Do your stuff."

They you would put your descriptor hacking in XMeta and still take
advantage of the original metaclass.

-eric

>
> Michael Foord
> --
> http://voidspace.org.uk/
> --
> http://mail.python.org/mailman/listinfo/python-list
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: how to dynamically generate __name__ for an object?

[Fuzzyman]

On Aug 10, 4:25 pm, Ian Kelly  wrote:
> On Wed, Aug 10, 2011 at 8:48 AM, Fuzzyman  wrote:
> > __name__ can be a descriptor, so you just need to write a descriptor
> > that can be fetched from classes as well as instances.
>
> > Here's an example with a property (instance only):
>
>  class Foo(object):
> > ...   @property
> > ...   def __name__(self):
> > ...     return 'bar'
> > ...
>  Foo().__name__
> > 'bar'
>
> But:
>
> >>> Foo.__name__
> 'Foo'

That's why I said "you just need to _write_ a descriptor that can be
fetched from classes as well as instances". The example with property
was to show that it *could* be a descriptor. You can write descriptors
with custom behaviour when fetched from a class.

However it turns out that you're right and I'm wrong; __name__ is
special:

>>> class descriptor(object):
...  def __get__(*args):
...   return 'bar'
...
>>> class Foo(object):
...  __name__ = descriptor()
...
>>> Foo.__name__
'Foo'
>>> Foo().__name__
'bar'
>>> class Foo(object):
...  name = descriptor()
...
>>> Foo.name
'bar'

As Eric points out in his original slot, types have their __name__
slot filled in with a string in typeobject.c

All the best,

Michael
--
http://voidspace.org.uk/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: __set__ method is not called for class attribute access

[Fuzzyman]

On Aug 10, 5:27 pm, Eric Snow  wrote:
> On Wed, Aug 10, 2011 at 8:33 AM, Fuzzyman  wrote:
> > On Aug 5, 12:29 pm, Ryan  wrote:
> >> In the context of descriptors, the __set__ method is not called for
> >> class attribute access. __set__ is only
> >> called to set the attribute on an instance instance of the owner class
> >> to a new value, value. WHY?
>
> > It's an unfortunate asymmetry in the descriptor protocol. You can
> > write "class descriptors" with behaviour on get, but not on set.
>
> > As others point out, metaclasses are an ugly way round this
> > (particularly given that *basically* a class can only have one
> > metaclass - so if you're inheriting from a class that already has a
> > custom metaclass you can't use this technique).
>
> Keep in mind that you can still do something like this:
>
> class XMeta(Base.__class__):
>     "Customize here"
>
> class X(Base, metaclass=XMeta):
>     "Do your stuff."
>
> They you would put your descriptor hacking in XMeta and still take
> advantage of the original metaclass.

Yeah, the way round the "more than one metaclass problem" is to have
your new metaclass inherit from the first one. That's not a general
purpose solution though.

Michael
--
http://voidspace.org.uk/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: how to dynamically generate __name__ for an object?

[Eric Snow]

On Wed, Aug 10, 2011 at 8:48 AM, Fuzzyman  wrote:
> On Aug 7, 4:06 am, Eric Snow  wrote:
>> Thought I knew how to provide a dynamic __name__ on instances of a
>> class.  My first try was to use a non-data descriptor:
>>
>> # module base.py
>>
>> class _NameProxy(object):
>>     def __init__(self, oldname):
>>         self.oldname = oldname
>>     def __get__(self, obj, cls):
>>         if obj is None:
>>             return self.oldname
>>         if "__name__" not in obj.__dict__:
>>             return str(obj.__context__)
>>         return obj.__name__
>>
>> class _BaseMeta(type):
>>     def __init__(cls, name, bases, namespace):
>>         cls.__name__ = _NameProxy(name)
>>
>> class Base(object):
>>     __metaclass__ = _BaseMeta
>>
>> $ python _base.py
>> Traceback (most recent call last):
>>   ...
>>   File "/usr/local/lib/python2.4/site-packages/base.py", line xx, in __init__
>>     cls.__name__ = _NameProxy(name)
>> TypeError: Error when calling the metaclass bases
>>     can only assign string to Base.__name__, not '_NameProxy'
>>
>> Needless to say I was surprised.  After looking in typeobject.c, I
>> believe that __name__ must be a string where classes are concerned[1].
>>  So if I want all my instances to have a __name__ attribute, and for
>> it to be dynamically provided if it isn't set on the instance, what
>> are my options?  Or maybe I did something wrong and it should work as
>> I expected?
>>
>
> __name__ can be a descriptor, so you just need to write a descriptor
> that can be fetched from classes as well as instances.
>
> Here's an example with a property (instance only):
>
 class Foo(object):
> ...   @property
> ...   def __name__(self):
> ...     return 'bar'
> ...
 Foo().__name__
> 'bar'

Thanks!  Your example is exactly what I didn't try in the first place,
but should have.  I was thinking of __name__ on a class as a simple
data attribute.  My original worry was that by adding a descriptor for
__name__ on my class, I would overwrite the name of the class, hence
the elaborate descriptor.

However, for type objects (classes) __name__ is a data descriptor and
the actual name isn't stored in __name__.  I was staring that right in
the face (the link I provided is for the setter method of the __name__
"property" for type objects).  I guess it was a "forest for the trees"
moment.

Because of attribute lookup in Python, "Base.__name__" uses the
equivalent of "Base.__class__.__name__.__get__(..., Base,
Base.__class__)".

Anyway, thanks for making me see how dumb I am!  

-eric

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

Re: allow line break at operators

[Seebs]

On 2011-08-10, Chris Angelico  wrote:
> And if we require {} then truly free indentation should be OK too! But
> it wouldn't be Python any more.

Would it really not be Python at all?

I've seen bits of code in preprocessing-based "Python with {}" type things,
and they still look like Python to me, only they favor explicit over
implicit a little more strongly.

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: SocketServer expceion after upgrading to 2.7

[Irmen de Jong]

On 10-08-11 15:42, Laszlo Nagy wrote:

Exception happened during processing of request from ('80.99.165.122',
56069)
Traceback (most recent call last):
File "/usr/local/lib/python2.7/SocketServer.py", line 284, in
_handle_request_noblock
self.process_request(request, client_address)
File "/usr/local/lib/python2.7/SocketServer.py", line 311, in
process_request
self.shutdown_request(request)
File "/usr/local/lib/python2.7/SocketServer.py", line 459, in
shutdown_request
request.shutdown(socket.SHUT_WR)
TypeError: shutdown() takes exactly 0 arguments (1 given)


I get this error with a program, after upgrading to python 2.7. I'm
using a program that is based on SocketServer and SimpleXMLRPCDispatcher.

Any idea how to fix this?


Strange, I expected at least one or two more stack frames in the 
traceback you posted (from within the socket.py module).


What platform are you on?
What python version?
What does this print on your system:

>>> import socket
>>> s=socket.socket()
>>> s.shutdown(socket.SHUT_WR)


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

Searching for Lottery drawing list of ticket match...

[MrPink]

I need a little nudge into the right direction with this problem.
As an exercise for me to learn about Python, I am trying to determine
the best way to search a list of "lottery drawings" for a match with a
lottery ticket.

Possible numbers for a drawing are:
5 whiteballs (wb): 1-55
1 blackball (bb): 1-49

example: wb1, wb2, wb3, wb4, wb5, bb

Example list of lottery drawings:
date,wb,wb,wb,wb,wb,bb
4/1/2011,5,1,45,23,27,27
5/1/2011,15,23,8,48,22,32
6/1/2011,33,49,21,16,34,1
7/1/2011,9,3,13,22,45,41
8/1/2011,54,1,24,39,35,18
...

Typically a lottery ticket can have multiple combinations for the
ticket to be a winner.  For example:
2 wb, 1 bb
3 wb
3 wb, 1 bb
4 wb
4 wb, 1 bb
5 wb
5 wb, 1 bb (jackpot winner)

An object oriented solution might be to create a list of "Drawing"
objects and then loop through the list to find a match for the ticket
object.  For example:
if oDrawing[x] == ticket then "Do XYZ"

Or I could just perform this task with procedures and loops and skip
the object solution idea.

Do Python developers have a preference?
Would it be worth the overhead to initialize a list of drawing objects
to search through?

There is no database back-end, so no SQL, etc.

I hope all that makes sense.
Thanks for you help.
-- 
http://mail.python.org/mailman/listinfo/python-list

Directions on accessing shared folder in windows network

[Ameet Nanda]

Hi,

Can anyone point me to a way to access windows shared folders from the
network using a python script. I tried accessing using open, which is
mentioned to work perfectly on the web, but it gives me following errors

>>>open(NW_PATH)

it gives me a permission denied error as follows:

>>> open("ameetn\\DropBox\\")
Traceback (most recent call last):
  File "", line 1, in 
IOError: [Errno 2] No such file or directory: 'ameetn\\'

>>> open("ameetn\\DropBox")
Traceback (most recent call last):
  File "", line 1, in 
IOError: [Errno 13] Permission denied: 'ameetn\\DropBox'

I am running Python 2.6 on Windows 7 platform.

Thanks in advance,
Ameet
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Directions on accessing shared folder in windows network

[MRAB]

On 10/08/2011 20:52, Ameet Nanda wrote:

Hi,

Can anyone point me to a way to access windows shared folders from the
network using a python script. I tried accessing using open, which is
mentioned to work perfectly on the web, but it gives me following errors

 >>>open(NW_PATH)

it gives me a permission denied error as follows:

 >>> open("ameetn\\DropBox\\")
Traceback (most recent call last):
   File "", line 1, in 
IOError: [Errno 2] No such file or directory: 'ameetn\\'

 >>> open("ameetn\\DropBox")
Traceback (most recent call last):
   File "", line 1, in 
IOError: [Errno 13] Permission denied: 'ameetn\\DropBox'

I am running Python 2.6 on Windows 7 platform.


"ameetn" is the name of the machine and "DropBox" is the name of a
shared folder on that machine.

The answer hasn't changed.

'open' is for opening _files_.

Give 'open' the path to a _file_.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Directions on accessing shared folder in windows network

[Christian Heimes]

Am 10.08.2011 21:52, schrieb Ameet Nanda:
> Hi,
> 
> Can anyone point me to a way to access windows shared folders from the
> network using a python script. I tried accessing using open, which is
> mentioned to work perfectly on the web, but it gives me following errors

The open() function wraps the fopen() function, which doesn't support
UNC, just local paths. You have to mount the network share first (assign
a drive letter).

Christian

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

Re: allow line break at operators

[Ben Finney]

Seebs  writes:

> On 2011-08-10, Chris Angelico  wrote:
> > And if we require {} then truly free indentation should be OK too!
> > But it wouldn't be Python any more.
>
> Would it really not be Python at all?

See the Python interpreter's response to ‘from __future__ import braces’.

> I've seen bits of code in preprocessing-based "Python with {}" type
> things, and they still look like Python to me, only they favor
> explicit over implicit a little more strongly.

They introduce unnecessary ambiguity: the indentation-as-structure and
braces-as-structure can then disagree.

In which case either the Python interpreter must guess the programmer's
intent (very un-Pythonic), or it throws an error and the programmer must
do busy-work to keep braces and indentation in agreement (also
un-Pythonic).

The ambiguity is resolved by having exactly one of indentation or braces
determining structure: Python uses indentation. In which case, braces
are pointless for indicating block structure.

-- 
 \“Without cultural sanction, most or all of our religious |
  `\  beliefs and rituals would fall into the domain of mental |
_o__) disturbance.” —John F. Schumaker |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: allow line break at operators

[Chris Angelico]

On Wed, Aug 10, 2011 at 10:51 PM, Ben Finney  wrote:
> Seebs  writes:
>> I've seen bits of code in preprocessing-based "Python with {}" type
>> things, and they still look like Python to me, only they favor
>> explicit over implicit a little more strongly.
>
> They introduce unnecessary ambiguity: the indentation-as-structure and
> braces-as-structure can then disagree.
>
> The ambiguity is resolved by having exactly one of indentation or braces
> determining structure: Python uses indentation. In which case, braces
> are pointless for indicating block structure.

That's why it wouldn't be Python. It would have to use the braces and
not the indentation.

ChrisA
PS. I mistakenly sent this to a Gilbert & Sullivan group first. Oddly
enough, opera-goers are not used to discussing the relative merits of
braces vs indentation in code.
-- 
http://mail.python.org/mailman/listinfo/python-list

problem installing psyco on windows (Unable to find vcvarsall.bat)

[Gelonida N]

Hi,

I'd like to install psyco on my windows host


I'm using python 2.6.4 (32 bit version)

I installed easy_intall and  pip

easy_install psyco
and
pip install psyco fail both with the message
error: Setup script exited with error: Unable to find vcvarsall.bat


I read, that this means I shoul dinstall a C-compiler
I also read, that I should NOT Micrusoft Visual C++ Express 2010
(which is unfortunately exactly the version, which I installed for some
other activity.


So my question:

- If I install visual Studio 2008 addtiojnally to visualstudia 2010,
will easy_install find this compiler?
- I read about the alternative of using MingW instead of Visual Studio
Express 2008.

What could influence my choice of Compiler?

Thanks for any suggestions


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

Re: Python & Sullivan

[Tim Chase]

On 08/10/2011 05:42 PM, Chris Angelico wrote:

PS. I mistakenly sent this to a Gilbert&  Sullivan group
first. Oddly enough, opera-goers are not used to discussing
the relative merits of braces vs indentation in code.


It's only fair turnabout:

http://coding.derkeiler.com/Archive/Python/comp.lang.python/2006-09/msg01783.html

-tkc



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

Re: allow line break at operators

[Steven D'Aprano]

Ian Kelly wrote:

> On Wed, Aug 10, 2011 at 8:37 AM, Steven D'Aprano
>  wrote:
>>> Without the parentheses, this is legal but (probably) useless; it
>>> applies the unary + operator to the return value of those functions.
>>> Putting the + at the end of the previous line at least prevents that,
>>> since most unary operators bind to the operand on the right;
>>
>> Not so:
>>
> x = (42 + -
>> ...     100)
>
> x
>> -58
> 
> That is still binding to the operand on the "right" (i.e., the
> sequentially later).  And it still does not cause the problem that
> Chris was talking about, since without the parentheses that would be a
> syntax error.  So I guess I'm not certain what exactly it is that
> you're trying to demonstrate here.

Chris stated that putting the unary + at the end of the line
prevents "that", that being applying the unary + operator to the value on
the right. But that is not the case -- unary prefix operators in Python can
be separated from their operands by whitespace, including newlines.

(Python doesn't have any unary postfix operators.)

 

-- 
Steven

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

Re: Docstrings and class Attributes

[Steven D'Aprano]

John Pinner wrote:

> On Aug 9, 1:36 am, Ben Finney  wrote:
>> Ethan Furman  writes:
>> > So if property docstrings are so hard to get to, what's the point in
>> > having them?
>>
>> Why would you expect there be a special point to them?
>>
>> Men, like all primates of any sex, have nipples.
>>
>> Properties, like any function in Python, have docstrings.
> 
> So are you saying that men's nipples are pointless?
> 
> You could be correct, except in cold weather maybe.

Groan.

However, off-topic but interesting, there is at least one species of bat
where the males are known to routinely lactate and feed baby bats.

http://en.wikipedia.org/wiki/Male_lactation

So just because a feature is an accident of history, doesn't mean that a use
can't be found for it.



-- 
Steven

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

Cookie Problem

[Jack Hatterly]

Hi;

I'm trying to get this cookie code to work but it doesn't set the 
properties I want set (expires, path, comment, etc.). When I delete the 
cookie and run the script it duly creates a cookie. However, when I 
reload the page none of the morsels have values associated with them. I 
also do not see values when I look for them in my FireFox CookieCuller. I
 pretty much copied this code from an online tutorial so I'm wondering 
where the problem is.



#!/usr/bin/env python



import string

import os

import datetime, Cookie, random

import time



ourTime = str(time.time())

cookie = Cookie.SimpleCookie()

cookie['lastvisit'] = str(time.time())



print cookie

print 'Content-Type: text/html\n'



print ''

print 'Server time is', time.asctime(time.localtime()), ''



# The returned cookie is available in the os.environ dictionary

cookie_string = os.environ.get('HTTP_COOKIE')



# The first time the page is run there will be no cookies

if not cookie_string:

print 'First visit or cookies disabled'

cookie = string.replace(ourTime, '.', '')

cookie = Cookie.SimpleCookie()

expiration = datetime.datetime.now() + datetime.timedelta(days=30)

cookie['lastvisit'] = str(time.time())

cookie['lastvisit']['expires'] = 30 * 24 * 60 * 60

cookie['lastvisit']['path'] = '/var/www/html/my_site/'

cookie['lastvisit']['comment'] = 'holds the last user\'s visit date'

cookie['lastvisit']['domain'] = '.www.my_site.com'

cookie['lastvisit']['max-age'] = 30 * 24 * 60 * 60

cookie['lastvisit']['secure'] = ''

cookie['lastvisit']['version'] = 1



else: # Run the page twice to retrieve the cookie

   print 'The returned cookie string was "' + cookie_string + '"'

#   cookie = string.replace(string.split(str(cookie['lastvisit']), '=')[1], 
'.', '')[:-1]

   # load() parses the cookie string

   cookie.load(cookie_string)

   # Use the value attribute of the cookie to get it

   lastvisit = float(cookie['lastvisit'].value)

   for morsel in cookie:

 print '', morsel, '=', cookie[morsel].value

 print ''

 for key in cookie[morsel]:

   print key, '=', cookie[morsel][key], ''

   print ''



print ''



TIA,

Jack

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

Re: Python & Sullivan

[Chris Angelico]

On Thu, Aug 11, 2011 at 12:26 AM, Tim Chase
 wrote:
> On 08/10/2011 05:42 PM, Chris Angelico wrote:
>>
>> PS. I mistakenly sent this to a Gilbert&  Sullivan group
>> first. Oddly enough, opera-goers are not used to discussing
>> the relative merits of braces vs indentation in code.
>
> It's only fair turnabout:
>
> http://coding.derkeiler.com/Archive/Python/comp.lang.python/2006-09/msg01783.html

Yes, I know about that one. My problem is that I snap off quick
responses to both lists, and sometimes type "sav" instead of "py" or
vice versa. Usually I catch it before hitting Send, though!!

On MUDs, we call that a mischannel. I've now mischanneled both directions. :|

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

Re: allow line break at operators

[Chris Angelico]

On Thu, Aug 11, 2011 at 12:32 AM, Steven D'Aprano
 wrote:
> Chris stated that putting the unary + at the end of the line
> prevents "that", that being applying the unary + operator to the value on
> the right. But that is not the case -- unary prefix operators in Python can
> be separated from their operands by whitespace, including newlines.
>

Right, I forgot that. It certainly would not be normal to do it that
way, though.

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

Puzzled about the output of my demo of a proof of The Euler Series

[Richard D. Moores]

I saw an interesting proof of the limit of The Euler Series on
math.stackexchange.com at
.
Scroll down to Hans Lundmark's post.

I thought I'd try to see this "pinching down" on the limit of pi**2/6.
See my attempt, and output for n = 150 at
. What puzzles me is that
upper_bound_partial_sum (lines 39 and 60) is always smaller than the
limit. It should be greater than the limit, right? If not, no pinching
between upper_bound_partial_sum and lower_bound_partial_sum.

I've checked and double-checked the computation, but can't figure out
what's wrong.

Thanks,

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

Re: allow line break at operators

[Steven D'Aprano]

Seebs wrote:

> On 2011-08-10, Chris Angelico  wrote:
>> And if we require {} then truly free indentation should be OK too! But
>> it wouldn't be Python any more.
> 
> Would it really not be Python at all?

Of course it wouldn't be. Every function, class, if, while, for,
try...except block etc. in existing Python code would be illegal if {} were
required. This would be an order of magnitude bigger change than going from
Python 2 to 3, where the biggest syntax change is that print is no longer a
statement.

Even more so if ; were to become required, as suggested by the Original
Poster.



> I've seen bits of code in preprocessing-based "Python with {}" type
> things, and they still look like Python to me, only they favor explicit
> over implicit a little more strongly.

"Looks like" Python does not equal "is Python". Cobra looks like Python, as
do Boo, Groovy and Ruby, or OCaml with "twt" turned on ("the whitespace
thing"). The similarities are especially strong for Boo and Cobra, but
there is no doubt that they are different languages.

In general, languages that aim to look like executable pseudo-code will
converge on a similar look, because executable pseudo-code tends to be
based on natural language (usually English) and mathematics syntax. 


-- 
Steven

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

code object differences between 2.7 and 3.3a

[Eric Snow]

Specifically, I am wondering why there is a difference for co_names.
Here is a function that exercises the different code object pieces[1]:

def g(y=5):
   a = 7
   def f(x, w=y, z=4, *args, **kwargs):
  b = a
  c = global_x
   return f

f1 = g()


Here are the results for 2.7:

>>> for name in dir(f1.func_code): print("%s -> %s" % (name, 
>>> getattr(f1.func_code, name)))
...
co_argcount -> 3
co_cellvars -> ()
co_code -> }t}dS
co_consts -> (None,)
co_filename -> 
co_firstlineno -> 3
co_flags -> 15
co_freevars -> ('a',)
co_lnotab ->
co_name -> f
co_names -> ('a', 'b', 'global_x', 'c')
co_nlocals -> 7
co_stacksize -> 1
co_varnames -> ('x', 'w', 'z', 'args', 'kwargs', 'c', 'b')


And for 3.3:

>>> for name in dir(f1.__code__): print("%s -> %s" % (name, 
>>> getattr(f1.__code__, name)))
...
co_argcount -> 3
co_cellvars -> ()
co_code -> b'\x88\x00\x00}\x05\x00t\x00\x00}\x06\x00d\x00\x00S'
co_consts -> (None,)
co_filename -> 
co_firstlineno -> 3
co_flags -> 31
co_freevars -> ('a',)
co_kwonlyargcount -> 0
co_lnotab -> b'\x00\x01\x06\x01'
co_name -> f
co_names -> ('global_x',)
co_nlocals -> 7
co_stacksize -> 1
co_varnames -> ('x', 'w', 'z', 'args', 'kwargs', 'b', 'c')


While there are several differences, the one I care about is co_name.
For 2.7 it's what I would expect.  However, for 3.3 it's not[2][3].
It is actually nicer for my application this way, but I want to verify
the situation before I get me hopes up. :)

Before I go email-list-diving or digging through PyEval_EvalCodeEx,  I
wanted to see if anyone has any insight about this change in co_names.
 Thanks!

-eric


[1] yes, 3.x also supports keyword-only arguments.  I tried this on
3.3 with extra kw-only arguments and it was the same outcome.
[2] The documentation for the inspect module gives an incomplete
listing of the code object attributes:
  The description of
co_names there ("tuple of names of local variables") seems
inconsistent with what I am seeing.  It's probably just that I am
misinterpreting that list or the doc needs an update.
[3] My guess is that co_names was seen as bloated and the superfluous
items removed, leaving only the un-closed free variables; co_freevars
is the closed free variables.  To get the same tuple as the 2.7
version, you could compose it from co_freevars, co_names, and the end
of co_varnames.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: allow line break at operators

[Chris Angelico]

On Thu, Aug 11, 2011 at 1:32 AM, Steven D'Aprano
 wrote:
>> I've seen bits of code in preprocessing-based "Python with {}" type
>> things, and they still look like Python to me, only they favor explicit
>> over implicit a little more strongly.
>
> "Looks like" Python does not equal "is Python". Cobra looks like Python, as
> do Boo, Groovy and Ruby, or OCaml with "twt" turned on ("the whitespace
> thing"). The similarities are especially strong for Boo and Cobra, but
> there is no doubt that they are different languages.
>
> In general, languages that aim to look like executable pseudo-code will
> converge on a similar look, because executable pseudo-code tends to be
> based on natural language (usually English) and mathematics syntax.

"Looks like" is a poor indication of anything much; "feels like" is a
bit vague, but may be more useful. If you can manipulate objects and
references to objects, if you can use Python's rich object set and
standard library, if you can use Python-like features using reasonably
readable syntax, then it feels like Python. Little things don't matter
(eg whether 'print' is a keyword or a function). Big things do (eg
having to explicitly deallocate objects).

Lots of languages "look like" C. Some of them function like C (eg
C++), and most definitely "feel like" C. Others don't.

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

Re: Python & Sullivan

[Ben Finney]

Tim Chase  writes:

> On 08/10/2011 05:42 PM, Chris Angelico wrote:
> > PS. I mistakenly sent this to a Gilbert&  Sullivan group
> > first. Oddly enough, opera-goers are not used to discussing
> > the relative merits of braces vs indentation in code.
>
> It's only fair turnabout:
>
> http://coding.derkeiler.com/Archive/Python/comp.lang.python/2006-09/msg01783.html

Also of interest: Do a web search for “debian dueling banjos”.

Or read about the phenomenon at http://gumbaby.com/?p=64>.

-- 
 \“The restriction of knowledge to an elite group destroys the |
  `\   spirit of society and leads to its intellectual |
_o__)impoverishment.” —Albert Einstein |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Docstrings and class Attributes

[Ben Finney]

Steven D'Aprano  writes:

> So just because a feature is an accident of history, doesn't mean that
> a use can't be found for it.

Which I explicitly noted in my message. I suppose it's inevitable for
the nuances of one's utterances to be forgotten as the discussion
progresses, but darn if it ain't annoying.

-- 
 \  “Not using Microsoft products is like being a non-smoker 40 or |
  `\ 50 years ago: You can choose not to smoke, yourself, but it's |
_o__)   hard to avoid second-hand smoke.” —Michael Tiemann |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list

Bizarre behavior of the 'find' method of strings

[Jim]

Greetings, folks,

I am using python 2.7.2. Here is something I got:
>>> a = 'popular'
>>> i = a.find('o')
>>> j = a.find('a')
>>> a[i:j]
'opul'

Well, I expected a[i:j] to be 'opula', and can't think of any reason why this 
is not happening. So, can anybody help me out about this? Thank you very much.

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

Re: Cookie Problem

[Chris Angelico]

On Thu, Aug 11, 2011 at 12:39 AM, Jack Hatterly
 wrote:
>     cookie['lastvisit'] = str(time.time())
>     cookie['lastvisit']['expires'] = 30 * 24 * 60 * 60
>     cookie['lastvisit']['path'] = '/var/www/html/my_site/'
>     cookie['lastvisit']['comment'] = 'holds the last user\'s visit date'
>     cookie['lastvisit']['domain'] = '.www.my_site.com'
>     cookie['lastvisit']['max-age'] = 30 * 24 * 60 * 60
>     cookie['lastvisit']['secure'] = ''
>     cookie['lastvisit']['version'] = 1

Some of these values look wrong. Your 'path' ought to be as the
browser sees it, and your 'domain' ditto; the only way that these
would make sense is if you're setting this cookie on a page such as:

http://foo.www.my_site.com/var/www/html/my_site/blah/blah

and you want to also see the cookie on the page:

http://bar.www.my_site.com/var/www/html/my_site/asdf/qwer

Otherwise, I would recommend omitting those elements and allowing the
defaults through.

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

Re: Bizarre behavior of the 'find' method of strings

[MRAB]

On 11/08/2011 02:24, Jim wrote:

Greetings, folks,

I am using python 2.7.2. Here is something I got:

a = 'popular'
i = a.find('o')
j = a.find('a')
a[i:j]

'opul'

Well, I expected a[i:j] to be 'opula', and can't think of any reason
why this is not happening. So, can anybody help me out about this?

> Thank you very much.



Python uses half-open ranges, which means that the start position is
inclusive and the end position is exclusive.

This means that a[i:j] returns the string starting at position i and
extending upto, but excluding, position j.

The reason that Python uses half-open ranges is that experience (with
the language Mesa) has shown that it results in fewer programming
errors that the alternatives.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Bizarre behavior of the 'find' method of strings

[Chris Angelico]

On Thu, Aug 11, 2011 at 2:48 AM, MRAB  wrote:
> Python uses half-open ranges, which means that the start position is
> inclusive and the end position is exclusive.
>

Or if you prefer: Python identifies positions between characters,
rather than characters. And I agree that it's better than the
alternative - in fact, I wish other systems could work the same way
(eg Bible references). If you think about position 0 being the very
beginning of the string, and position len(s) being the very end, then
you slice the string from position to position and take the characters
between. When you index the string for a particular character, you aim
at a position and take the character after it.

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

PyCon Australia 2011: Registration Closing Soon!

[Ryan Kelly]

Hi Everyone,


Registrations for PyCon Australia 2011 are closing soon!

The conference is just over a week away, so we need final numbers in the
next few days.  If you're planning to attend, please register now!

PyCon Australia is Australia's only conference dedicated exclusively to
the Python programming language, and will be held at the Sydney Masonic
Center over the weekend of August 20 and 21. See below for more
information and updates on:
 
 1. Registration Closing Soon
 2. Coffee
 3. Hosting Panel
 4. More Sponsors Announced
 
Please pass this message on to those you feel may be interested.

 

Registration Closing Soon
=

Full Registrations for the conference will be closing on:

Monday 15th August:  Full Registrations close

That's only five days away, so register now to be sure you don't
miss out.

By request, we will still allow latecomers to register until just before
the conference.  However, since it's after the deadline for catering and
printing, you won't be entitled to a T-shirt or a seat at the conference
dinner:

Thursday 18th August:  Last-Minute Registrations close

Please note that we will *not* accept registrations at the door.

So don't delay, register now at:

http://pycon-au.org/reg



Coffee
==

Thanks to gold sponsors Arclight, we will be able to provide one of the
most requested additions to this year's conference:  Coffee!

Yes, Arclight have generously agreed to provide a free coffee cart for
the duration of the conference.  And there was much rejoicing.



Hosting Panel
=

Saturday evening will feature an informal panel discussion with several
hosting providers.  Come and hear from our hosting panel about why their
services are right for hosting your next Python project! Each group will
give a quick 5 minute spiel, to be followed by a casual drink before the
conference dinner.

This event is happening in a private area at Mr B's pub, across the street
from the SMC. As this is a licensed venue anyone under 18 will have to be
accompanied by a parent or guardian.



More Sponsors Announced
===

We are delighted to confirm that the Django Software Foundation and Ninefold
have joined as Silver sponsors.  In addition, Arclight have upgraded to Gold
Sponsorship, Anchor have agreed to sponsor video production, and GitHub will
be sponsoring internet access.

Thanks once again to the following companies for their continuing support of
Python and for helping to make PyCon Australia 2011 a reality:


Gold:  Google 
Gold:  ComOps 
Gold:  Arclight   
 
Video:  Anchor

Silver:  Enthought
Silver:  Python Software Foundation   
Silver:  WingWare 
Silver:  Bitbucket by Atlassian   
Silver:  Microsoft
Silver:  Django Software Foundation   
Silver:  Ninefold 

Internet:  GitHub 


Thanks also to Linux Australia, who provide the overarching legal and
organisational structure for PyCon Australia.



Ryan Kelly
PyCon Australia 2011



-- 
Ryan Kelly
http://www.rfk.id.au  |  This message is digitally signed. Please visit
r...@rfk.id.au|  http://www.rfk.id.au/ramblings/gpg/ for details

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

[ANNC] pynguin-0.11 python turtle graphics application

[Lee Harr]

Pynguin is a python-based turtle graphics application.
    It combines an editor, interactive interpreter, and
    graphics display area.

It is meant to be an easy environment for introducing
    some programming concepts to beginning programmers.


http://pynguin.googlecode.com/


This release continues to expand basic functionality and
    explores more user-friendly options in the interface.


Pynguin is tested with Python 2.7.1 and PyQt 4.8.3 and
    will use Pygments syntax highlighting if available.

Pynguin is released under GPLv3.


Changes in pynguin-0.11:
    Session
    - all settings now moved in to menus and settings dialogs

    Pynguin API
    - added .label() method to have a label attached to a pynguin
    - also accessible as .name attribute
    - added .speed() method to change speed from user code
    - viewcoords() now returns integers by default
    - pass floats=True to get the float values instead
    - added .track() and .notrack() methods for user code

    Canvas
    - added support for custom avatars
    - both svg and bitmap images supported
    - fixed motion when drawing slow circles with pen up
    - don't draw circles when pen is up and speed is instant
    - expand canvas when resizing window

    Integrated Editor
    - added "Test / Run all" button
    - improved handling of external .py files

    Integrated Console
    - now gives correct call syntax when using test/run on classes

    Examples
    - make examples use new viewcoords() API
    - fixed multi.pyn scatter example
    - make multi.pyn follow examples work with existing pynguins
    - demonstrate labels in multi.pyn follow example
    - fix penup() in oo.pyn ZZ example
    - add centered circle in oo.pyn ZZ example

    General
    - fixed examples getting gzipped in .deb distribution file
    - added a way to dump contents of .pyn from command line

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

Re: allow line break at operators

[Yingjie Lan]

:And if we require {} then truly free indentation should be OK too! But

:it wouldn't be Python any more.

Of course, but not the case with ';'. Currently ';' is optional in Python,
But '{' is used for dicts. Clearly, ';' and '{' are different in magnitude.

So the decision is: shall we change ';' from optional to mandatory
to allow free line splitting?

Yingjie

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

Re: Bizarre behavior of the 'find' method of strings

[Steven D'Aprano]

On Thu, 11 Aug 2011 11:24 am Jim wrote:

> Greetings, folks,
> 
> I am using python 2.7.2. Here is something I got:
 a = 'popular'
 i = a.find('o')
 j = a.find('a')
 a[i:j]
> 'opul'
> 
> Well, I expected a[i:j] to be 'opula', and can't think of any reason why
> this is not happening. So, can anybody help me out about this? Thank you
> very much.

Your subject line says:

Bizarre behavior of the 'find' method of strings

What makes you think this is a problem with the find method?

As a programmer, you should be able to isolate where the problem *actually*
occurs:

>>> a = 'popular'
>>> a.find('o')
1
>>> a.find('a')
5

So there is no problem with the find method: it correctly finds the index
(starting at zero, not one) of the first (going left-to-right) matching
substring.

Now, if you take a slice, you get an unexpected (to you) result:

>>> a[1:5]
'opul'

It doesn't matter where the 1 and 5 come from. The slice can't tell that
they were the output of find, or how they were generated:

>>> a[1000-999:20/4]
'opul'

Now that you have isolated the actual problem, you can ask a better
question:

"Why does slicing not work the way I expect?"

Answer: because Python uses half-open slices, where the end parameter is not
included. The reason for that is that experience with other languages shows
that it leads to fewer "off-by-one" errors.

See also:

http://mail.python.org/pipermail/tutor/2010-December/080592.html
http://en.wikipedia.org/wiki/Off-by-one_error



-- 
Steven

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

Re: allow line break at operators

[Yingjie Lan]

On Wed, Aug 10, 2011 at 1:58 PM, Yingjie Lan  wrote:

> Is it possible for python to allow free splitting of single-line statements
> without the backslashes, if we impose that expressions can only be split
> when it is not yet a finished expression?

:The trouble is that in a lot of cases, the next statement after an
:unfinished expression could conceivably be a continuation of it. If
:this were permitted, it would have to also require that the
:continuation lines be indented, to avoid the problem described above.
:It'd still have the potential to mis-diagnose errors, though.

Indentation is a good idea to reduce the likelihood of such troubles.
and also produce code that is easier to read.

Yingjie

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

Re: problem installing psyco on windows (Unable to find vcvarsall.bat)

[Miki Tebeka]

You can download the sources tarball and when building specify the compiler.
See http://docs.python.org/install/index.html#gnu-c-cygwin-mingw
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: multiprocessing timing issue

[Philip Semanchuk]

On Aug 9, 2011, at 1:07 PM, Tim Arnold wrote:

> Hi, I'm having problems with an empty Queue using multiprocessing.
> 
> The task:
> I have a bunch of chapters that I want to gather data on individually and 
> then update a report database with the results.
> I'm using multiprocessing to do the data-gathering simultaneously.
> 
> Each chapter report gets put on a Queue in their separate processes. Then 
> each report gets picked off the queue and the report database is updated with 
> the results.
> 
> My problem is that sometimes the Queue is empty and I guess it's
> because the get_data() method takes a lot of time.
> 
> I've used multiprocessing before, but never with a Queue like this.
> Any notes or suggestions are very welcome.


Hi Tim,
THis might be a dumb question, but...why is it a problem if the queue is empty? 
It sounds like you figured out already that get_data() sometimes takes longer 
than your timeout. So either increase your timeout or learn to live with the 
fact that the queue is sometimes empty. I don't mean to be rude, I just don't 
understand the problem. 

Cheers
Philip

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

Re: Searching for Lottery drawing list of ticket match...

[Miki Tebeka]

Python built in types are enough for this problem IMO. You can use sets of 
tuples to specify ticket and drawings and then just do set intersection.

Say the drawing is set([(5, 'wb'), (1, 'wb'), (45, 'wb'), (23, 'wb'), (27, 
'wb')]) (keeping black ball out). The you can create a score function:

Side note: I might used a namedtuple to have drawing.whites, drawing.black.

def score(ticket_whites, ticket_black, drawing_whites, drawing_black):
num_whites = ticket_whites & drawing_whites
black_matching = ticket_black == drawing_black
return {
(2, True)  : 1,
(3, False) : 2,
(3, True)  : 3,
(4, False) : 4,
(4, True)  : 5,
(5, False) : 6,
(5, True)  : 10
}[(num_whites, black_matching)]
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Bizarre behavior of the 'find' method of strings

[Chris Rebert]

On Wed, Aug 10, 2011 at 7:56 PM, Steven D'Aprano
 wrote:
> On Thu, 11 Aug 2011 11:24 am Jim wrote:
>
>> Greetings, folks,
>>
>> I am using python 2.7.2. Here is something I got:
> a = 'popular'
> i = a.find('o')
> j = a.find('a')
> a[i:j]
>> 'opul'
>>
>> Well, I expected a[i:j] to be 'opula', and can't think of any reason why
>> this is not happening. So, can anybody help me out about this? Thank you
>> very much.

> "Why does slicing not work the way I expect?"
>
> Answer: because Python uses half-open slices, where the end parameter is not
> included. The reason for that is that experience with other languages shows
> that it leads to fewer "off-by-one" errors.
>
> See also:
>
> http://mail.python.org/pipermail/tutor/2010-December/080592.html
> http://en.wikipedia.org/wiki/Off-by-one_error

And further:
http://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD831.html

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

Re: problem installing psyco on windows (Unable to find vcvarsall.bat)

[Dan Stromberg]

FWIW, a few months ago I was working on a database application on Windows,
and I benchmarked the psyco-enhanced version consistently running slower
than the non-psyco version.  The same code on Linux was faster with psyco
though.

If you need performance, and you aren't constrained by module availability,
you probably should use PyPy instead.

On Wed, Aug 10, 2011 at 3:44 PM, Gelonida N  wrote:

> Hi,
>
> I'd like to install psyco on my windows host
>
>
> I'm using python 2.6.4 (32 bit version)
>
> I installed easy_intall and  pip
>
> easy_install psyco
> and
> pip install psyco fail both with the message
> error: Setup script exited with error: Unable to find vcvarsall.bat
>
>
> I read, that this means I shoul dinstall a C-compiler
> I also read, that I should NOT Micrusoft Visual C++ Express 2010
> (which is unfortunately exactly the version, which I installed for some
> other activity.
>
>
> So my question:
>
> - If I install visual Studio 2008 addtiojnally to visualstudia 2010,
> will easy_install find this compiler?
> - I read about the alternative of using MingW instead of Visual Studio
> Express 2008.
>
> What could influence my choice of Compiler?
>
> Thanks for any suggestions
>
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: allow line break at operators

[Chris Rebert]

On Wed, Aug 10, 2011 at 7:52 PM, Yingjie Lan  wrote:
> :And if we require {} then truly free indentation should be OK too! But
>
> :it wouldn't be Python any more.
>
> Of course, but not the case with ';'. Currently ';' is optional in Python,

I think of it more as that Python deigns to permit semicolons.

> But '{' is used for dicts. Clearly, ';' and '{' are different in magnitude.
>
> So the decision is: shall we change ';' from optional to mandatory
> to allow free line splitting?

Hell no, considering that the sizable majority of lines *aren't*
split, which makes those semicolons completely redundant to their
accompanying newlines. We'd be practicing poor Huffman coding by
optimizing for the *un*common case. It would also add punctuational
noise to what is otherwise an amazingly clean and readable syntax.
Accidental semicolon omission is (IMO) the most irritating source of
syntax (and, inadvertently, sometimes other more serious) errors in
curly-braced programming languages.

Such a core syntax feature is not going to be changed lightly (or likely ever).

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

Re: allow line break at operators

[Steven D'Aprano]

On Thu, 11 Aug 2011 12:52 pm Yingjie Lan wrote:

> :And if we require {} then truly free indentation should be OK too! But
> 
> :it wouldn't be Python any more.
> 
> Of course, but not the case with ';'. Currently ';' is optional in Python,
> But '{' is used for dicts. Clearly, ';' and '{' are different in
> magnitude.
> 
> So the decision is: shall we change ';' from optional to mandatory
> to allow free line splitting?

Why on earth would you want to break backwards compatibility of millions of
Python scripts and programs, and require extra, unnecessary line-noise on
every single line of Python code, just so that you can occasionally avoid a
writing a pair of parentheses?

This will never happen. Forget it. Python is more likely to get static types
than compulsory semi-colons.


-- 
Steven

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

Re: Bizarre behavior of the 'find' method of strings

[Jim]

Thanks for all you guys. Now I got it. 

To Steven,
I was in a little rush when I put this post.  But you are right. It's not the 
find method's problem. 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: allow line break at operators

[Michael Trausch]

Perhaps it could be made an optional thing to enable; for example, some
languages by default do dynamic typing, but with an option contained as the
first statement of the file can enforce static typing.
On Aug 10, 2011 10:57 PM, "Yingjie Lan"  wrote:
> :And if we require {} then truly free indentation should be OK too! But
>
> :it wouldn't be Python any more.
>
> Of course, but not the case with ';'. Currently ';' is optional in Python,
> But '{' is used for dicts. Clearly, ';' and '{' are different in
magnitude.
>
> So the decision is: shall we change ';' from optional to mandatory
> to allow free line splitting?
>
> Yingjie
>
> --
> http://mail.python.org/mailman/listinfo/python-list
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: allow line break at operators

[Seebs]

On 2011-08-11, Steven D'Aprano  wrote:
> Seebs wrote:
>> On 2011-08-10, Chris Angelico  wrote:
>>> And if we require {} then truly free indentation should be OK too! But
>>> it wouldn't be Python any more.

>> Would it really not be Python at all?

> Of course it wouldn't be. Every function, class, if, while, for,
> try...except block etc. in existing Python code would be illegal if {} were
> required.

So?

Since there has never been an indentation-related problem in the history
of human endeavors, automatically adding the braces would be completely
trivial.

How much of the language *specification* would change?

> In general, languages that aim to look like executable pseudo-code will
> converge on a similar look, because executable pseudo-code tends to be
> based on natural language (usually English) and mathematics syntax. 

This is an interesting point.  I guess I meant "look like" in a more abstract
sense; the basic idea of what it's like to read the code, and what you have
to keep in mind while doing so.

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: allow line break at operators

[Chris Rebert]

> On Aug 10, 2011 10:57 PM, "Yingjie Lan"  wrote:
>> :And if we require {} then truly free indentation should be OK too! But
>>
>> :it wouldn't be Python any more.
>>
>> Of course, but not the case with ';'. Currently ';' is optional in Python,
>> But '{' is used for dicts. Clearly, ';' and '{' are different in
>> magnitude.
>>
>> So the decision is: shall we change ';' from optional to mandatory
>> to allow free line splitting?

On Wed, Aug 10, 2011 at 9:51 PM, Michael Trausch  wrote:
> Perhaps it could be made an optional thing to enable; for example, some
> languages by default do dynamic typing, but with an option contained as the
> first statement of the file can enforce static typing.

I am intrigued. What languages(s) have the feature you refer to?

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

Re: allow line break at operators

[Seebs]

On 2011-08-10, Ben Finney  wrote:
> Seebs  writes:
>> On 2011-08-10, Chris Angelico  wrote:
>> > And if we require {} then truly free indentation should be OK too!
>> > But it wouldn't be Python any more.

>> Would it really not be Python at all?

> See the Python interpreter's response to ???from __future__ import braces???.

I'm aware of that.  I have seen all the counterarguments, and what I've
mostly become convinced of is this:

1.  Indentation as flow control was a bad idea.
2.  People are subconsciously aware of this.
3.  There is a HUGE degree of emotional investment in defending it.

The responses I have seen on this issue are highly emotional, full of insults,
full of blame-throwing, and utterly contrary to the basic engineering spirit
I usually see in programming communities.  In other languages, and even in
Python on any issue but this one, I regularly see people acknowledge
shortcomings and explain either why they think the tradeoffs are good, or why
they are willing to put up with it anyway.

The characteristic vehemence and hostility this issue produces are the surest
sign of people who have a desperate need not to acknowledge the elephant in
the room.

>> I've seen bits of code in preprocessing-based "Python with {}" type
>> things, and they still look like Python to me, only they favor
>> explicit over implicit a little more strongly.

> They introduce unnecessary ambiguity: the indentation-as-structure and
> braces-as-structure can then disagree.

Yes, they can.

> In which case either the Python interpreter must guess the programmer's
> intent (very un-Pythonic), or it throws an error and the programmer must
> do busy-work to keep braces and indentation in agreement (also
> un-Pythonic).

The obvious answer would be:

* Braces win because they are explicit rather than implicit.
* Everyone would use things configured to throw a warning or error.

The thing is...  This whole argument rests on the assumption that if there
are no braces, there is only one set of things, but if you have braces,
there are two.

This is untrue.

If there are no braces, there are two things describing flow control;
indentation and programmer intent.  With braces, there's three.

The most common misalignment is between the code as interpreted by the
computer and the programmer's intent.  Neither system prevents this, but
that's where all the real hassle comes from.

My expectation would be that the only times braces and indentation
would be "ambiguous" would be cases where the indentation got screwed up.

In these cases, I would MUCH prefer to get a fatal error than to have
things run in a way entirely unrelated to the intent I had when I wrote
the code.

> The ambiguity is resolved by having exactly one of indentation or braces
> determining structure: Python uses indentation. In which case, braces
> are pointless for indicating block structure.

I don't think so, any more than I think parentheses which happen to align
with the existing precendence rules are pointless.

In the real world, we are confronted constantly with tools which work
perfectly with every programming language but Python or very old FORTRAN,
but which mangle Python code sporadically and inexplicably.  Mail servers
chew up whitespace like there's no tomorrow.  Web pages find innovative new
explanations for why those leading spaces don't need to be displayed.

I like Python a lot in some ways, but I am really sick of the insistance that
this godawful wart is the sublime epitome of all perfection, never to be
improved on.  It was a really interesting experiment.  As sometimes happens,
the experiment discovered things that no one could have reasonably anticipated
without running the experiment.

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: allow line break at operators

[Michael Trausch]

VB (classic; .NET versions no longer have it) had an "option explicit" where
you had to define each variable explicitly, otherwise by default you created
variables simply by assigning to them.

They did it that way to enable backwards compatibility for those who wanted
the old style. Most people wound up using "option explicit" and it is now
the default (and afaik only, but I don't use vb.net so I cannot say that for
sure) way of doing things.

Somthing like an "option" keyword (which would only be a keyword until the
first executable statement, e.g., would have to be before even imports)
could enable things like "semicolon" or "explicit", or whatever really, and
only affect those who opt in. If no code is ever seen using the option, it
can even be removed. Wouldn't be a bad way to test changes that would impact
the syntax of the language, actually...
On Aug 11, 2011 1:07 AM, "Chris Rebert"  wrote:
>> On Aug 10, 2011 10:57 PM, "Yingjie Lan"  wrote:
>>> :And if we require {} then truly free indentation should be OK too! But
>>>
>>> :it wouldn't be Python any more.
>>>
>>> Of course, but not the case with ';'. Currently ';' is optional in
Python,
>>> But '{' is used for dicts. Clearly, ';' and '{' are different in
>>> magnitude.
>>>
>>> So the decision is: shall we change ';' from optional to mandatory
>>> to allow free line splitting?
>
> On Wed, Aug 10, 2011 at 9:51 PM, Michael Trausch  wrote:
>> Perhaps it could be made an optional thing to enable; for example, some
>> languages by default do dynamic typing, but with an option contained as
the
>> first statement of the file can enforce static typing.
>
> I am intrigued. What languages(s) have the feature you refer to?
>
> Cheers,
> Chris
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: multiprocessing timing issue

[Tim Roberts]

Tim Arnold  wrote:
>
>The task:
>I have a bunch of chapters that I want to gather data on individually 
>and then update a report database with the results.
>I'm using multiprocessing to do the data-gathering simultaneously.
>
>Each chapter report gets put on a Queue in their separate processes. 
>Then each report gets picked off the queue and the report database is 
>updated with the results.
>
>My problem is that sometimes the Queue is empty and I guess it's
>because the get_data() method takes a lot of time.
>
>I've used multiprocessing before, but never with a Queue like this.
>Any notes or suggestions are very welcome.

The obvious implication is that your timeout is simply not long enough for
your common cases.  If you know how many chapters to expect, why have a
timeout at all?  Why not just wait forever?
-- 
Tim Roberts, t...@probo.com
Providenza & Boekelheide, Inc.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Puzzled about the output of my demo of a proof of The Euler Series

[casevh]

On Aug 10, 4:57 pm, "Richard D. Moores"  wrote:
> I saw an interesting proof of the limit of The Euler Series on
> math.stackexchange.com at
> .
> Scroll down to Hans Lundmark's post.
>
> I thought I'd try to see this "pinching down" on the limit of pi**2/6.
> See my attempt, and output for n = 150 at
> . What puzzles me is that
> upper_bound_partial_sum (lines 39 and 60) is always smaller than the
> limit. It should be greater than the limit, right? If not, no pinching
> between upper_bound_partial_sum and lower_bound_partial_sum.
>
> I've checked and double-checked the computation, but can't figure out
> what's wrong.
>
> Thanks,
>
> Dick Moores

The math is correct. The proof only asserts that sum(1/k^2) is between
the upper and lower partial sums. The upper and lower partial sums
both converge to pi^2/6 from below and since the sum(1/k^2) is between
the two partial sums, it must also converge to pi^2/6.

Try calculating sum(1/k^2) for k in range(1, 2**n) and compare that
with the upper and lower sums. I verified it with several values up to
n=20.

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

Re: allow line break at operators

[Ben Finney]

Seebs  writes:

> On 2011-08-10, Ben Finney  wrote:
> > Seebs  writes:
> >> On 2011-08-10, Chris Angelico  wrote:
> >> > And if we require {} then truly free indentation should be OK too!
> >> > But it wouldn't be Python any more.
>
> >> Would it really not be Python at all?
>
> > See the Python interpreter's response to ???from __future__ import 
> > braces???.
>
> I'm aware of that. I have seen all the counterarguments, and what I've
> mostly become convinced of is this:
>
> 1.  Indentation as flow control was a bad idea.
> 2.  People are subconsciously aware of this.

What evidence do you have of these? The latter, especially, seems to be
mere opinion unfounded in any measurement.

> 3.  There is a HUGE degree of emotional investment in defending it.

That same observation is consistent with:

* Indentation as block syntax is an excellent idea.
* Python programmers are quite consciously aware of this.

So I don't see a reason to prefer your inference over mine.

> The responses I have seen on this issue are highly emotional, full of
> insults, full of blame-throwing

Again, I don't know where you've been observing that, but it's not what
I've seen.

> I like Python a lot in some ways, but I am really sick of the
> insistance that this godawful wart is the sublime epitome of all
> perfection, never to be improved on. It was a really interesting
> experiment. As sometimes happens, the experiment discovered things
> that no one could have reasonably anticipated without running the
> experiment.

You're welcome to attempt to demonstrate the superiority of some other
Python-with-braces, but it will (a) be un-Pythonic, and (b) be unlikely
to gain the efforts of people who don't think what you're addressing is
a problem.

Since that latter set of people includes most Python programmers who
have reacted negatively to the proposal, you may want to re-think
whether your effort is worthwhile. Meanwhile, we'll continue being
productive with Python's indentation-as-structure.

-- 
 \ “If nature has made any one thing less susceptible than all |
  `\others of exclusive property, it is the action of the thinking |
_o__)  power called an idea” —Thomas Jefferson, 1813-08-13 |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: String concatenation - which is the fastest way ?

[przemolicc]

On Wed, Aug 10, 2011 at 06:20:10PM +0200, Stefan Behnel wrote:
> przemol...@poczta.fm, 10.08.2011 15:31:
>> On Wed, Aug 10, 2011 at 01:32:06PM +0100, Chris Angelico wrote:
>>> On Wed, Aug 10, 2011 at 12:17 PM,  wrote:
 I'd like to write a python (2.6/2.7) script which connects to database, 
 fetches
 hundreds of thousands of rows, concat them (basically: create XML)
 and then put the result into another table. Do I have any choice
 regarding string concatenation in Python from the performance point of 
 view ?
 Since the number of rows is big I'd like to use the fastest possible 
 library
 (if there is any choice). Can you recommend me something ?
>>>
>>> First off, I have no idea why you would want to create an XML dump of
>>> hundreds of thousands of rows, only to store it in another table.
>>> However, if that is your intention, list joining is about as efficient
>>> as you're going to get in Python:
>>>
>>> lst=["asdf","qwer","zxcv"] # feel free to add 399,997 more list entries
>>> xml=""+"".join(lst)+""
>>>
>>> This sets xml to 'asdfqwerzxcv' which
>>> may or may not be what you're after.
>>
>> since this process (XML building) is running now inside database (using 
>> native SQL commands)
>> and is one-thread task it is quite slow. What I wanted to do is to spawn 
>> several python subprocesses in parallel which
>> will concat subset of the whole table (and then merge all of them at the 
>> end).
>> Basically:
>> - fetch all rows from the database (up to 1 million): what is recommended 
>> data type ?
>> - spawn X python processes each one:
>>  - concat its own subset
>> - merge the result from all the subprocesses
>>
>> This task is running on a server which has many but slow cores and I am 
>> trying to divide this task
>> into many subtasks.
>
> Makes sense to me. Note that the really good DBMSes (namely, PostgreSQL)  
> come with built-in Python support.

The data are in Oracle so I have to use cx_oracle.

> You still didn't provide enough information to make me understand why you 
> need XML in between one database and another (or the same?), but if you 
> go that route, you can just read data through multiple connections in 
> multiple threads (or processes), have each build up one (or more) XML 
> entries, and then push those into a queue. Then another thread (or more 
> than one) can read from that queue and write the XML items into a file 
> (or another database) as they come in.

I am not a database developer so I don't want to change the whole process
of data flow between applications in my company. Another process is
reading this XML from particular Oracle table so I have to put the final XML 
there.

> If your data has a considerable size, I wouldn't use string concatenation 
> or joining at all (note that it requires 2x the memory during  
> concatenation), but rather write it into a file, or even just process the 
> data on the fly, i.e. write it back into the target table right away.  
> Reading a file back in after the fact is much more resource friendly than 
> keeping huge amounts of data in memory. And disk speed is usually not a  
> problem when streaming data from disk into a database.

This server has 256 GB of RAM so memory is not a problem.
Also the select which fetches the data is sorted. That is why I have to 
carefully divide into subtasks and then merge it in correct order.

Regards
Przemyslaw Bak (przemol)




















































Dom marzen - kup lub wynajmij taniej niz myslisz!
Szukaj >> http://linkint.pl/f2a0d
-- 
http://mail.python.org/mailman/listinfo/python-list