Re: confusing doc: mutable and hashable

[Arnaud Delobelle]

(sent from my phone)
On Apr 28, 2012 7:36 PM, "Chris Rebert"  wrote:
> Correct. Pedantically, you can define __hash__() on mutable objects;
> it's just not very useful or sensible, so people generally don't.

I find it's fine to define __hash__ on mutable objects as long as __eq__
only relies on immutable state (and then so should __hash__ of course).  A
typical example would be an object that does some caching.

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

Re: Learn Technical Writing from Unix Man in 10 Days

[Cameron Simpson]

On 29Apr2012 02:49, Steven D'Aprano  
wrote:
| On Sat, 28 Apr 2012 14:55:42 -0700, Xah Lee wrote:
| > Learn Technical Writing from Unix Man in 10 Days
| > 
| > Quote from man apt-get:
| > 
| > remove
| > remove is identical to install except that packages are
| > removed
| > instead of installed.
| 
| Do you also expect the documentation to define "except", "instead", "is", 
| "to" and "the"?

Of course he doesn't. But he may have expected something less trite from
the sentence, not that that would really make it more clear.

| If you don't know what "install" and "remove" means, then you need an 
| English dictionary, not a technical manual.

Well, the sentence _is_ on par with several Haynes manuals which say
after the "remove/access motorcycle/car component": "installation is the
reverse of the disassembly". Fair enough.

However, I notice that my Haynes manuals on livestock do not include
this sentence in the butchering chapters:-)

Cheers,
-- 
Cameron Simpson  DoD#743
http://www.cskk.ezoshosting.com/cs/

Ride Free, Ride Nude!   - David Jevans 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Communication between C++ server and Python app

[Cameron Simpson]

On 29Apr2012 11:42, Chris Angelico  wrote:
| On Sun, Apr 29, 2012 at 10:45 AM, kenk  
wrote:
| > I've got a server process written in C++ running on Unix machine.
| > On the same box I'd like to run multiple Python scripts that will
| > communicate with this server.
| >
| > Can you please suggest what would be best was to achieve this ?
| 
| Personally, I would recommend a TCP socket, because that allows the
| flexibility of splitting across multiple computers.

And the pain of ensuring security, if you're in an open network.

| But for
| efficiency, you may want to consider a Unix socket too.

A UNIX socket or even a named pipe has the benefit of:
  - not being available remotely
  - access control with normal UNIX permissions
and of course efficiency as you say.

Generalising to a TCP socket later shouldn't be too hard if the need
arises.

Cheers,
-- 
Cameron Simpson  DoD#743
http://www.cskk.ezoshosting.com/cs/

Waiting for the bus is a bad idea if you turn out to be the bus driver.
- Michael M. Butler on the Singularity
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Communication between C++ server and Python app

[Rodrick Brown]

What interfaces are available on the server process? 

Sent from my iPad

On Apr 28, 2012, at 8:45 PM, kenk  wrote:

> Hi,
> 
> I've got a server process written in C++ running on Unix machine.
> On the same box I'd like to run multiple Python scripts that will
> communicate with this server.
> 
> Can you please suggest what would be best was to achieve this ?
> 
> Kind regards and thanks in advance!
> M.
> -- 
> http://mail.python.org/mailman/listinfo/python-list
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Learn Technical Writing from Unix Man in 10 Days

[Steven D'Aprano]

On Sat, 28 Apr 2012 14:55:42 -0700, Xah Lee wrote:

> Learn Technical Writing from Unix Man in 10 Days
> 
> Quote from man apt-get:
> 
> remove
> remove is identical to install except that packages are
> removed
> instead of installed.


Do you also expect the documentation to define "except", "instead", "is", 
"to" and "the"?

If you don't know what "install" and "remove" means, then you need an 
English dictionary, not a technical manual.



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

Re: confusing doc: mutable and hashable

[Terry Reedy]

On 4/28/2012 2:09 PM, laymanzh...@gmail.com wrote:


In my understanding, there is no directly relation between mutable
and hashable in Python. Any class with __hash__ function is
"hashable".

According the wiki: http://en.wikipedia.org/wiki/Immutable_object

In object-oriented and functional programming, an immutable object is
an object whose state cannot be modified after it is created.[1] This
is in contrast to a mutable object, which can be modified after it is
created.

We surely can define __hash__ function in user-define class and the
instance of that class can be changed thus mutable.


The default hash is based on the immutable value of an object. If you 
base a custom hash on values that do change, it is not useful as a dict key.


--
Terry Jan Reedy

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

Re: Communication between C++ server and Python app

[Roy Smith]

In article 
<108cb846-6bb9-4600-a984-2fded0c91...@er9g2000vbb.googlegroups.com>,
 kenk  wrote:

> Hi,
> 
> I've got a server process written in C++ running on Unix machine.
> On the same box I'd like to run multiple Python scripts that will
> communicate with this server.
> 
> Can you please suggest what would be best was to achieve this ?

There are so many reasonable answers, it's hard to know where to start.  
Perhaps if you could give us some clue as to what the server does, it 
might help.

What kind of data are you passing back and forth?  Text?  Binary?  Is it 
important that the communication be as efficient as possible, or is it 
more important that the code be easy to write?  Are you worried about 
security?  Will you ever need to interoperate with other systems written 
in other languages?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Communication between C++ server and Python app

[Chris Angelico]

On Sun, Apr 29, 2012 at 10:45 AM, kenk  wrote:
> Hi,
>
> I've got a server process written in C++ running on Unix machine.
> On the same box I'd like to run multiple Python scripts that will
> communicate with this server.
>
> Can you please suggest what would be best was to achieve this ?

Personally, I would recommend a TCP socket, because that allows the
flexibility of splitting across multiple computers. But for
efficiency, you may want to consider a Unix socket too.

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

Communication between C++ server and Python app

[kenk]

Hi,

I've got a server process written in C++ running on Unix machine.
On the same box I'd like to run multiple Python scripts that will
communicate with this server.

Can you please suggest what would be best was to achieve this ?

Kind regards and thanks in advance!
M.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Getting started with PyGTK [Receiving Error]

[Vincent Vande Vyvre]

Le 29/04/12 00:52, Santosh Kumar a écrit :
> System Information
> 
> Ubuntu 11.10
> Python 2.7.2
>
> Problem
> 
>
> I think my Ubuntu has PyGTK and GTK both already installed. But
> however when I am importing "gtk" in Python interactive mode then I am
> getting the following warning:
>
> (.:4126): Gtk-WARNING **: Unable to locate theme engine in
> module_path: "pixmap",
>
> (.:4126): Gtk-WARNING **: Unable to locate theme engine in
> module_path: "pixmap",
>
> (.:4126): Gtk-WARNING **: Unable to locate theme engine in
> module_path: "pixmap",
>
> (.:4126): Gtk-WARNING **: Unable to locate theme engine in
> module_path: "pixmap",
>
> On the other side, importing "PyGTK" works well (i.e. I don't receive
> any error). What might be error?
It's a behaviour of GTK, not an error in your code.

I use PyQt and I've always theses warnings under KDE and Unity, never
under Gnome.

I thing you can ignore it.

-- 
Vincent V.V.
Oqapy  . Qarte+7
 . PaQager 

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

Re: Learn Technical Writing from Unix Man in 10 Days

[Andrew Berg]

On 4/28/2012 6:45 PM, Temia Eszteri wrote:
> Professional? He's boring!
I agree. Ranting Rick is much more entertaining (usually).

-- 
CPython 3.2.3/3.3.0a2 | Windows NT 6.1.7601.17790
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Learn Technical Writing from Unix Man in 10 Days

[Temia Eszteri]

>On Sun, Apr 29, 2012 at 8:36 AM, Temia Eszteri  wrote:
>> And what does this have to do with a multiplatform language like
>> Python? :P
>
>Nothing. Xah Lee is a professional troll. You can save yourself some
>trouble by ignoring his posts altogether.
>
>ChrisA

Professional? He's boring! I wanted to see if I could poke him into
action. I know, I know, "don't feed the trolls." Just wanted to see if
he would actually come up with something interesting.

~Temia
--
When on earth, do as the earthlings do.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: confusing doc: mutable and hashable

[MRAB]

On 28/04/2012 23:30, Temia Eszteri wrote:

Yes, you're right. Being mutable and hashable are orthogonal properties.
The implication
 mutable =>  non hashable
is just a design choice.

The reason for such a choice is the following. If a key-element pair K:X
is added to a container C and then K is changed by some external Python
code without letting C know of this change, C may become inconsistent.
Some containers (e.g. set) assume that K=X and just take X. Modifying X
is equivalent to modifying K in the example above.
These kinds of problems are avoided if mutable objects can't be keys.
Some containers require that keys be hashable, but since, by design,
mutable objects can't be keys, there's no reason for them to be hashable
either.

Kiuhnm


Well, if worst comes to worst and you wind up in a programming
situation where you needed to make a mutable object as a hash entry,
it's still possible to subclass the object type and have __hash__()
return the object's ID instead, right?

I can only think of a few edge cases where that could even possibly be
required though, such as membership testing for something and having a
callback associated with each set of members...


If objects x and y of the same class are mutable and you want them to
have the same hash if x == y then having __hash__() return the object's
ID is not what you want.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Learn Technical Writing from Unix Man in 10 Days

[Chris Angelico]

On Sun, Apr 29, 2012 at 8:36 AM, Temia Eszteri  wrote:
> And what does this have to do with a multiplatform language like
> Python? :P

Nothing. Xah Lee is a professional troll. You can save yourself some
trouble by ignoring his posts altogether.

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

Getting started with PyGTK [Receiving Error]

[Santosh Kumar]

System Information

Ubuntu 11.10
Python 2.7.2

Problem


I think my Ubuntu has PyGTK and GTK both already installed. But
however when I am importing "gtk" in Python interactive mode then I am
getting the following warning:

(.:4126): Gtk-WARNING **: Unable to locate theme engine in
module_path: "pixmap",

(.:4126): Gtk-WARNING **: Unable to locate theme engine in
module_path: "pixmap",

(.:4126): Gtk-WARNING **: Unable to locate theme engine in
module_path: "pixmap",

(.:4126): Gtk-WARNING **: Unable to locate theme engine in
module_path: "pixmap",

On the other side, importing "PyGTK" works well (i.e. I don't receive
any error). What might be error?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Learn Technical Writing from Unix Man in 10 Days

[Temia Eszteri]

And what does this have to do with a multiplatform language like
Python? :P

~Temia
--
When on earth, do as the earthlings do.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: confusing doc: mutable and hashable

[Temia Eszteri]

>Yes, you're right. Being mutable and hashable are orthogonal properties.
>The implication
> mutable => non hashable
>is just a design choice.
>
>The reason for such a choice is the following. If a key-element pair K:X 
>is added to a container C and then K is changed by some external Python 
>code without letting C know of this change, C may become inconsistent.
>Some containers (e.g. set) assume that K=X and just take X. Modifying X 
>is equivalent to modifying K in the example above.
>These kinds of problems are avoided if mutable objects can't be keys.
>Some containers require that keys be hashable, but since, by design, 
>mutable objects can't be keys, there's no reason for them to be hashable 
>either.
>
>Kiuhnm

Well, if worst comes to worst and you wind up in a programming
situation where you needed to make a mutable object as a hash entry,
it's still possible to subclass the object type and have __hash__()
return the object's ID instead, right?

I can only think of a few edge cases where that could even possibly be
required though, such as membership testing for something and having a
callback associated with each set of members...

~Temia
--
When on earth, do as the earthlings do.
-- 
http://mail.python.org/mailman/listinfo/python-list

Learn Technical Writing from Unix Man in 10 Days

[Xah Lee]

Learn Technical Writing from Unix Man in 10 Days

Quote from man apt-get:

remove
remove is identical to install except that packages are
removed
instead of installed.

Translation:

kicking
kicking is identical to kissing except that receiver is kicked
instead of kissed.

further readings:

• 〈The Idiocy of Computer Language Docs〉
http://xahlee.org/comp/idiocy_of_comp_lang.html

• 〈Why Open Source Documentation is of Low Quality〉
http://xahlee.org/UnixResource_dir/writ/gubni_papri.html

• 〈Python Documentation Problems〉
http://xahlee.org/perl-python/python_doc_index.html



DISAPPEARING URL IN DOC

so, i was reading man git. Quote:

Formatted and hyperlinked version of the latest git documentation
can
be viewed at http://www.kernel.org/pub/software/scm/git/docs/.

but if you go to that url, it shows a list of over one hundred fourty
empty dirs.

I guess unix/linux idiots can't be bothered to have correct
documentation. Inability to write is one thing, but they are unable to
maintain a link or update doc?

does this ever happens to Apple's docs? If it did, i don't ever recall
seeing it from 18 years of using Mac.

more records of careless dead link:

• 〈Hackers: Dead Links and Human Compassion?〉
http://xahlee.org/comp/hacker_dead_links_and_compassion.html

• 〈Why Qi Lisp Fails and Clojure Succeeds〉
http://xahlee.org/UnixResource_dir/writ/qi_lang_marketing.html

• 〈unix: Hunspell Path Pain〉
http://xahlee.org/comp/hunspell_spell_path_pain.html

• 〈Python Doc URL disappearance〉
http://xahlee.org/perl-python/python_doc_url_disappearance.html

• 〈A Record of Frustration in IT Industry; Disappearing FSF URLs〉
http://xahlee.org/emacs/gnu_doc.html
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: confusing doc: mutable and hashable

[Kiuhnm]

On 4/28/2012 20:09, laymanzh...@gmail.com wrote:

I'm just learning Python. The python doc about mutable and hashable is 
confusing to me.

In my understanding, there is no directly relation between mutable and hashable in 
Python. Any class with __hash__ function is "hashable".

According the wiki: http://en.wikipedia.org/wiki/Immutable_object

In object-oriented and functional programming, an immutable object is an object 
whose state cannot be modified after it is created.[1] This is in contrast to a 
mutable object, which can be modified after it is created.

We surely can define __hash__ function in user-define class and the instance of 
that class can be changed thus mutable.

But following statement seems correct in practice but not technically. Any 
comments on this?

Thanks,
Andy


http://docs.python.org/py3k/library/stdtypes.html#set-types-set-frozenset:
   Since it is mutable, it has no hash value and cannot be used as either a 
dictionary key or as an element of another set.



Yes, you're right. Being mutable and hashable are orthogonal properties.
The implication
mutable => non hashable
is just a design choice.

The reason for such a choice is the following. If a key-element pair K:X 
is added to a container C and then K is changed by some external Python 
code without letting C know of this change, C may become inconsistent.
Some containers (e.g. set) assume that K=X and just take X. Modifying X 
is equivalent to modifying K in the example above.

These kinds of problems are avoided if mutable objects can't be keys.
Some containers require that keys be hashable, but since, by design, 
mutable objects can't be keys, there's no reason for them to be hashable 
either.


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

Re: syntax for code blocks

[Ethan Furman]

Kiuhnm wrote:
I'd like to change the syntax of my module 'codeblocks' to make it more 
pythonic.


Current Syntax:

with res << func(arg1) << 'x, y':
print(x, y)

with res << func(arg1) << block_name << 'x, y':
print(x, y)

New Syntax:

with res == func(arg1) .taking_block (x, y):
print(x, y)

with res == func(arg1) .taking_block (x, y) as block_name:
print(x, y)

The full form is equivalent to

def anon_func(x, y):
print(x, y)
res = func(arg1, block_name = anon_func)

Suggestions?


I don't find either the current syntax nor the new syntax pythonic.

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

From the crest of Olivet...

[E Bmums]

"From the crest of Olivet, Jesus looked upon Jerusalem. Fair and 
peaceful was the scene spread out before Him. It was the season of the 
Passover, and from all lands the children of Jacob had gathered there to 
celebrate the great national festival. In the midst of gardens and 
vineyards, and green slopes studded with pilgrims’ tents, rose the 
terraced hills, the stately palaces, and massive bulwarks of Israel’s 
capital. The daughter of Zion seemed in her pride to say, "I sit a 
queen, and shall see no sorrow;" as lovely then, and deeming herself as 
secure in Heaven’s favor, as when, ages before, the royal minstrel sang, 
"Beautiful for situation, the joy of the whole earth, is Mount Zion," 
"the city of the great King." Psalm 48:2. In full view were the 
magnificent buildings of the temple. The rays of the setting sun lighted 
up the snowy whiteness of its marble walls, and gleamed from golden gate 
and tower and pinnacle. "The perfection of beauty" it stood, the pride 
of the Jewish nation. What child of Israel could gaze upon the scene 
without a thrill of joy and admiration! But far other thoughts occupied 
the mind of Jesus. "When He was come near, He beheld the city, and wept 
over it." Luke 19:41. Amid the universal rejoicing of the triumphal 
entry, while palm branches waved, while glad hosannas awoke the echoes 
of the hills, and thousands of voices declared Him king, the world’s 
Redeemer was overwhelmed with a sudden and mysterious sorrow. He, the 
Son of God, the Promised One of Israel, whose power had conquered death, 
and called its captives from the grave, was in tears, not of ordinary 
grief, but of intense, irrepressible agony."   

...The Great Controversy Between Christ and Satan


Download the complete book (and Bibles) for free, from the mirrors 
below.


The Great Controversy Between Christ and Satan:

http://i.minus.com/1335372595/0E6HVZrNm7ay0jgHn6IUOA/dbzr787oXlIHFr.pdf
https://rapidshare.com/files/1649741361/The_Great_Controversy.pdf
https://hotfile.com/dl/153737170/594e2f9/The_Great_Controversy.pdf.html
http://www.MegaShare.com/4139813
http://netload.in/dateiynzi7FBtgz/The%20Great%20Controversy.pdf.htm
http://ul.to/25lsg6io
http://www.filefactory.com/file/2uk8o7ertopb/n/The_Great_Controversy_pdf
http://depositfiles.com/files/c7wvwxmlc
http://ifile.it/y6b49zr/The_Great_Controversy.pdf
http://filemonster.net/file/23514/the-great-controversy.pdf.html
http://www.crocko.com/F0F90DF9D43A44529E60EEB4A576E0F6/The_Great_Controv
ersy.pdf
http://www.mediafire.com/?gv4zmzrfrod9z7t
http://www.2shared.com/document/KS-GuN80/The_Great_Controversy.html
http://filevelocity.com/ugq737saizw5/The_Great_Controversy.pdf.html
http://freakshare.com/files/py3p1qtk/The_Great_Controversy.pdf.html
http://www.sendspace.com/file/105rd3
http://www.queenshare.com/66tz8u53sy91
http://www17.zippyshare.com/v/37604967/file.html
http://bayfiles.com/file/8kKT/YDv484/The_Great_Controversy.pdf


Updated King James Version Bible:

http://i.minus.com/1335372623/_-C-jUJbdr3M4lV0JUVdCg/dxqA2tjjwSdKQ.pdf
https://rapidshare.com/files/335715109/Updated_KJV_Bible.pdf
https://hotfile.com/dl/153737253/7ced0dc/Updated_KJV_Bible.pdf.html
http://www.MegaShare.com/4139832
http://netload.in/dateiyR6qK2G4WZ/Updated_KJV_Bible.pdf.htm
http://ul.to/adxm95v1
http://www.filefactory.com/file/tgzxk55g69h/n/Updated_KJV_Bible_pdf
http://depositfiles.com/files/u2rfflkp3
http://ifile.it/ya8dq26/Updated_KJV.pdf
http://filemonster.net/file/23515/updated-kjv.pdf.html
http://www.crocko.com/75C6C5C50B9F4F38A39CFC1207262933/Updated_KJV.pdf
http://www.mediafire.com/?354xtxmotc2s6iv
http://www.2shared.com/document/iw8XU2qR/Updated_KJV.html
http://filevelocity.com/celvp2pcrx5i/Updated_KJV.pdf.html
http://freakshare.com/files/v2g7k9d6/Updated_KJV.pdf.html
http://www.sendspace.com/file/lay7a6
http://www.queenshare.com/7vvv85z8trct
http://www11.zippyshare.com/v/65110611/file.html
http://bayfiles.com/file/8kMx/yuLJqD/Updated_KJV.pdf


NIV Bible:

http://i.minus.com/1335372583/-PZp68TwyHujBc5DFsmLiA/d7ElQRFQHz7ql.pdf
https://rapidshare.com/files/2600857109/NIV_Bible.pdf
https://hotfile.com/dl/153737311/3d73850/NIV_Bible.pdf.html
http://www.MegaShare.com/4139835
http://netload.in/dateiQ2Ew7dYzfx/NIV_Bible.pdf.htm
http://ul.to/58ik4f71
http://www.filefactory.com/file/48o1dxc83bj/n/NIV_Bible_pdf
http://depositfiles.com/files/bf8sz3dfn
http://ifile.it/tup0kg4/NIV.pdf
http://filemonster.net/file/23513/niv.pdf.html
http://www.crocko.com/CC2F7D7D6F124DA8BDA05601F67EFBEE/NIV.pdf
http://www.mediafire.com/?6uh6f2fzexq34lz
http://www.2shared.com/document/XXd3Licj/NIV.html
http://filevelocity.com/3i8kfkjpjiyv/NIV.pdf.html
http://freakshare.com/files/t8wldv5g/NIV.pdf.html
http://www.sendspace.com/file/qdgfvp
http://www.queenshare.com/v0ktceewuhkl
http://www1.zippyshare.com/v/65742413/file.html
http://bayfiles.com/file/8kNN/2zlsl8/NIV.pdf
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: CPython thread starvation

[Paul Rubin]

Roy Smith  writes:
> I agree that application-level name cacheing is "wrong", but sometimes 
> doing it the wrong way just makes sense.  I could whip up a simple 
> cacheing wrapper around getaddrinfo() in 5 minutes.  Depending on the 
> environment (both technology and bureaucracy), getting a cacheing 
> nameserver installed might take anywhere from 5 minutes to a few days to ...

IMHO this really isn't one of those times.  The in-app wrapper would
only be usable to just that process, and we already know that the OP has
multiple processes running the same app on the same machine.  They would
benefit from being able to share the cache, so now your wrapper gets
more complicated.  If it's not a nameserver then it's something that
fills in for one.  And then, since the application appears to be a large
scale web spider, it probably wants to run on a cluster, and the cache
should be shared across all the machines.  So you really probably want
an industrial strength nameserver with a big persistent cache, and maybe
a smaller local cache because of high locality when crawling specific
sites, etc.

Also, since this is a production application, doing something in 5
minutes is less important than making it solid and configurable.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: (3.2) Overload print() using the C API?

[Stefan Behnel]

Peter Faulks, 27.04.2012 22:31:
> On 27/04/2012 6:55 PM, Stefan Behnel wrote:
>> Peter Faulks, 27.04.2012 10:36:
>>> On 27/04/2012 5:15 PM, Stefan Behnel wrote:
 Peter Faulks, 26.04.2012 19:57:
> I want to extend an embedded interpreter so that calls to print() are
> automagically sent to a C++ gui (windows exe) via a callback function in
> the DLL.
>
> Then I'll be able to do this:
>
> test.py
> import printoverload
>
> printoverload.set_stdout()
> printoverload.set_stderr()
>
> print("this will be sent to a C function in printoverload.pyd")
> ---

 Why would you want to divert only "print" instead of changing
 sys.stdout in
 general? Not all output comes from print calls.

>>> Because I don't want to have to poll the stdout buffer.
>>
>> You don't have to. It's delivered right at your door and even rings the
>> bell when it arrives to hand over the parcel in person.
>>
>>
>>> I want the script
>>> itself to update a window in the host application (via the extension) every
>>> time the script calls print().
>>
>> Then replace sys.stdout (and maybe also sys.stderr) by another object that
>> does what you want whenever its write() method is called.
>>
>>
>>> But I guess that won't work if the script raises an exception...
>>
>> Yep, you better catch those yourself. The C-API function you use for
>> executing the Python code in the first place will tell you when there was
>> an error.
>>
>> BTW, my mention of Cython wasn't just a joke. You might want to look at it
>> because it makes these things essentially trivial compared to plain C-API
>> code in C.
> 
> OK, I _think_ I'm getting warmer... But I wonder, do I need to create new
> sys.stdout / sys.stderr objects? Can I not simply assign a custom C
> function to the write() methods of the existing sys.stdout / sys.stderr
> objects?

You can try it in Python code.

In any case, writing a class that does what you want is likely not more
than a few lines of Cython code, including the interaction with Qt. It's
certainly more involved in C code, but you can still write a part of it in
Python code there and just implement a write() function in C to stick it
into a regular Python class.

Stefan

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

Re: confusing doc: mutable and hashable

[Chris Rebert]

On Sat, Apr 28, 2012 at 11:09 AM,   wrote:
> I'm just learning Python. The python doc about mutable and hashable is 
> confusing to me.
>
> In my understanding, there is no directly relation between mutable and 
> hashable in Python. Any class with __hash__ function is "hashable".
>
> According the wiki: http://en.wikipedia.org/wiki/Immutable_object
>
> In object-oriented and functional programming, an immutable object is an 
> object whose state cannot be modified after it is created.[1] This is in 
> contrast to a mutable object, which can be modified after it is created.
>
> We surely can define __hash__ function in user-define class and the instance 
> of that class can be changed thus mutable.
>
> But following statement seems correct in practice but not technically. Any 
> comments on this?

Correct. Pedantically, you can define __hash__() on mutable objects;
it's just not very useful or sensible, so people generally don't. As
http://docs.python.org/reference/datamodel.html#object.__hash__ states
[emphasis added]:

"If a class defines *mutable* objects and implements a __cmp__() or
__eq__() method, it *should not* implement __hash__(), since hashable
collection implementations require that a object’s hash value is
immutable (if the object’s hash value changes, it will be in the wrong
hash bucket)."

> 
> http://docs.python.org/py3k/library/stdtypes.html#set-types-set-frozenset:
>  Since it is mutable, it has no hash value and cannot be used as either a 
> dictionary key or as an element of another set.
> 

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

Re: confusing doc: mutable and hashable

[mwilson]

laymanzh...@gmail.com wrote:

> I'm just learning Python. The python doc about mutable and hashable is
> confusing to me.
> 
> In my understanding, there is no directly relation between mutable and
> hashable in Python. Any class with __hash__ function is "hashable".
> 
> According the wiki: http://en.wikipedia.org/wiki/Immutable_object
> 
> In object-oriented and functional programming, an immutable object is an
> object whose state cannot be modified after it is created.[1] This is in
> contrast to a mutable object, which can be modified after it is created.
> 
> We surely can define __hash__ function in user-define class and the
> instance of that class can be changed thus mutable.
> 
> But following statement seems correct in practice but not technically. Any
> comments on this?

Wikipedia has it right.  Mutable objects are objects where significant 
attributes of the object can change value over the lifetime of the object.  
This is useful for data sharing.  If, for example, one part of your program 
knows an object by the name `a`, and another part knows the same object as 
`b` (or if they can access the object in any other distinct ways), they can 
communicate by changing values of attributes of the shared object. 

In practice, hashable means that the hashable object can be used as a key in 
a dict.  Looking up an item in a dict means that 1) the hash of the lookup 
key has to match the hash of the stored key, and 2) the lookup key has to be 
equal to the stored key according to the `==` operator.  These requirements 
are easy to meet if the keys are immutable.  Otherwise for classes you 
create, you can (if you're careful) create __hash__ and __eq__ methods to 
meet the requirements, even if significant attributes of your instances can 
change their values.

Mel.

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

confusing doc: mutable and hashable

[laymanzheng]

I'm just learning Python. The python doc about mutable and hashable is 
confusing to me. 

In my understanding, there is no directly relation between mutable and hashable 
in Python. Any class with __hash__ function is "hashable". 

According the wiki: http://en.wikipedia.org/wiki/Immutable_object

In object-oriented and functional programming, an immutable object is an object 
whose state cannot be modified after it is created.[1] This is in contrast to a 
mutable object, which can be modified after it is created.

We surely can define __hash__ function in user-define class and the instance of 
that class can be changed thus mutable. 

But following statement seems correct in practice but not technically. Any 
comments on this?

Thanks,
Andy


http://docs.python.org/py3k/library/stdtypes.html#set-types-set-frozenset:
  Since it is mutable, it has no hash value and cannot be used as either a 
dictionary key or as an element of another set.

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

Re: Python id() does not return an address [was Re: why () is () and [] is [] work in other way?]

[OKB (not okblacke)]

Adam Skutt wrote:

>> You can't treat id() as an address. Did you miss my post when I
>> demonstrated that Jython returns IDs generated on demand, starting
>> from 1? In general, there is *no way even in principle* to go from
>> a Python ID to the memory location (address) of the object with
>> that ID, because in general objects *may not even have a fixed
>> address*. Objects in Jython don't, because the Java virtual
>> machine can move them in memory. 
> 
> Yes, there is a way.  You add a function deref() to the language.

This is getting pretty absurd.  By that logic you could say "With 
Python, you can end all life on earth!  You just add a function to 
the language called nuclear_winter() that remotely accesses warhead 
launch sites in the US and Russia, enters the appropriate launch codes, 
and launches the entire nuclear arsenal!"

-- 
--OKB (not okblacke)
Brendan Barnwell
"Do not follow where the path may lead.  Go, instead, where there is
no path, and leave a trail."
--author unknown
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: beautiful bitch accepts dwarf

[jimmy970]

http://python.6.n6.nabble.com/file/n4936643/op4.jpg 

--
View this message in context: 
http://python.6.n6.nabble.com/AMPUTEE-INCEST-MIDGET-2012-tp4708963p4936643.html
Sent from the Python - python-list mailing list archive at Nabble.com.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: CPython thread starvation

[Chris Angelico]

On Sun, Apr 29, 2012 at 12:27 AM, Danyel Lawson  wrote:
> I'm glad I thought of it. ;) But the trick is to use port 5353 and set
> a really short timeout on responses in the config for the DNS cache.

I don't think false timeouts are any better than true ones, if you
actually know the true ones. But sure, whatever you need.

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

Re: CPython thread starvation

[Danyel Lawson]

I'm glad I thought of it. ;) But the trick is to use port 5353 and set
a really short timeout on responses in the config for the DNS cache.

On Sat, Apr 28, 2012 at 10:15 AM, Chris Angelico  wrote:
> On Sat, Apr 28, 2012 at 11:46 PM, Danyel Lawson  
> wrote:
>> The DNS lookup is one of those things that may make sense to run as a
>> separate daemon process that listens on a socket.
>
> Yeah, it does. One that listens on port 53, TCP and UDP, perhaps. :)
>
> You've just recommended installing a separate caching resolver.
>
> ChrisA
> --
> http://mail.python.org/mailman/listinfo/python-list
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: why () is () and [] is [] work in other way?

[Adam Skutt]

On Apr 28, 7:26 am, Kiuhnm  wrote:
> On 4/27/2012 19:15, Adam Skutt wrote:
> > On Apr 27, 11:01 am, Kiuhnm  wrote:
> >> The abstraction is this:
> >> - There are primitives and objects.
> >> - Primitives are not objects. The converse is also true.
> >> - Primitives can become objects (boxing).
> >> - Two primitives x and y are equal iff x == y.
> >> - Two objects x and y are equal iff x.equals(y).
> >> - Two objects are the same object iff x == y.
> >> - If x is a primitive, then y = x is a deep copy.
> >> - If x is an object, then y = x is a shallow copy.
> >> - ...
>
> > This is not an abstraction at all, but merely a poor explanation of
> > how things work in Java.  Your last statement is totally incorrect, as
> > no copying of the object occurs whatsoever.  The reference is merely
> > reseated to refer to the new object. If you're going to chide me for
> > ignoring the difference between the reference and the referent object,
> > then you shouldn't ignore it either, especially in the one case where
> > it actually matters!  If we try to extend this to other languages,
> > then it breaks down completely.
>
> With shallow copy I meant exactly that. I didn't think that my using the
> term with a more general meaning would cause such a reaction.

It has a very strict, well-defined meaning in these contexts,
especially in languages such as C++.

>
> So you're saying that I said that "Primitive constructs are references".
> Right...

No, still wrong.  What I said is correct, "References are a form of
primitive construct".  In C, an int is a primitive but not a
reference.  An int* is a pointer (reference), and is also
(essentially) a primitive.

>
> >  While true, it's still a bad way
> > to think about what's going on.  It breaks down once we add C++ /
> > Pascal reference types to the mix, for example.
>
> ?

Assignment to a C++ reference (T&) effects the underlying object, not
the reference itself.  A reference can never be reseated once it is
bound to an object.  Comparing equality on two references directly is
the same as comparing two values (it calls operator==).  Comparing
identity requires doing (&x == &y), like one would do with a value.
However, unlike a value, the object is not destroyed when the
reference goes out of scope.  Most importantly, references to base
classes do not slice derived class objects, so virtual calls work
correctly through references.

As a result, normally the right way to think about a value is as a
"temporary name" for an object and not worry about any of the details
about how the language makes it work.

>
> >> Equality or equivalence is a relation which is:
> >> - reflexive
> >> - symmetric
> >> - transitive
> >> Everything else... is something else. Call it semi-equality,
> >> tricky-equality or whatever, but not equality, please.
>
> > Sure, but then it's illegal to allow the usage of '==' with floating
> > point numbers, which will never have these properties in any usable
> > implementation[1].
>
> ???
>

The operator == is called the equality operator.  Floating-point
numbers don't really obey those properties in any meaningful fashion.
The result is that portions of your view contradict others.  Either we
must give '==' a different name, meaning what you consider equality is
irrelevant, or we must use method names like 'equals', which you find
objectionable.

> >>> If anything, you have that backwards.  Look at Python: all variables
> >>> in Python have pointer semantics, not value semantics.
>
> >> When everything is "white", the word "white" becomes redundant.
> >> So the fact that everything in Python have reference semantics means
> >> that we can't stop thinking about value and reference semantics.
>
> > Nope. The behavior of variables is absolutely essential to writing
> > correct programs.  If I write a program in Python that treats
> > variables as if they were values, it will be incorrect.
>
> You misunderstood what I said. You wouldn't treat variables as if they
> were values because you wouldn't even know what that means and that
> that's even a possibility.

Well, one hopes that is true.  I think we have a misunderstanding over
language: you said "value and reference semantics" when you really
meant "value vs. reference semantics".

> I've never heard an old C programmer talk about "value semantics" and
> "reference semantics". When everything is a value, your world is pretty
> simple.

Except if that were true, the comp.lang.c FAQ wouldn't have this
question and answer: http://c-faq.com/ptrs/passbyref.html, and several
others.

Much as you may not like it, most code doesn't care about a pointer's
value, doesn't need to know anything about it, and would just as soon
pretend that it doesn't exist.  All it really wants is a controlled
way to mutate objects in different scopes.  Which is precisely why
references are preferred over pointers in C++, as they're a better
expression of programmer intent, and far safe as a result.

Peaking under the covers in an

Re: CPython thread starvation

[Chris Angelico]

On Sat, Apr 28, 2012 at 11:46 PM, Danyel Lawson  wrote:
> The DNS lookup is one of those things that may make sense to run as a
> separate daemon process that listens on a socket.

Yeah, it does. One that listens on port 53, TCP and UDP, perhaps. :)

You've just recommended installing a separate caching resolver.

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

Re: int object

[Emile van Sebille]

On 4/27/2012 11:42 PM Debashish Saha said...

  44 sph_yn_P=(l*sph_yn(l,K*R)/(K*R))-sph_yn(l,K*R)


Here you're clearly multiplying by R...


--->  45 Beta_l=l-(K_P*R(sph_jv(l+1,K_P*R))/(sph_jv(l,K_P*R)))


... and here you've got R(...) which is attempting to call R() which 
isn't defined as a functions and is not callable.  Looks like you need 
to fix your formula.


Emile




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

Re: CPython thread starvation

[Danyel Lawson]

Sprinkle time.sleep(0) liberally throughout your code where you think
natural processing breaks should be.  Even in while loops. It's lame
but is the only way to make Python multithreading task switch fairly.
Your compute intensive tasks need a time.sleep(0) in their loops. This
prevents starvation and makes overall processing and responsiveness
seem properly multithreaded. This is a hand optimization so you have
to play with the location and amount of time.sleep(0)s. You'll know
when you've found a problematic spot when the queues stop
growing/overflowing.

Put the dns lookup on a separate thread pool with it's own growing
queue with lots of time.sleep(0)s sprinkled in. The dns lookups don't
have to be real time and you can easily cache them with a timestamp
attached. This is the thread pool where more is better and threads
should be aggressively terminated for having a long running process
time. This also requires lots of hand tuning for dynamically managing
the number of threads needed to process the queue in a reasonable time
if you find it hard to aggressively kill threads. I think there is a
way to launch threads that only give them a maximum lifetime. The
problem you will hit while tuning may require allocating more file
handles for all the hung sockets.

The DNS lookup is one of those things that may make sense to run as a
separate daemon process that listens on a socket. You make one
connection that feeds in the ip addresses. The daemon process feeds
back ip address/host name combinations out of order. Your main
process/connection thread builds a serialized access dict with
timestamps. The main processes threads make their requests
asynchronously and sleep while waiting for the response to appear in
the dict. They terminate after a certain time if they don't see their
response. Requires hand/algorithmic tweaking for this to work
correctly across different machines.

On Fri, Apr 27, 2012 at 2:54 PM, John Nagle  wrote:
>    I have a multi-threaded CPython program, which has up to four
> threads.  One thread is simply a wait loop monitoring the other
> three and waiting for them to finish, so it can give them more
> work to do.  When the work threads, which read web pages and
> then parse them, are compute-bound, I've had the monitoring thread
> starved of CPU time for as long as 120 seconds.
> It's sleeping for 0.5 seconds, then checking on the other threads
> and for new work do to, so the work thread isn't using much
> compute time.
>
>   I know that the CPython thread dispatcher sucks, but I didn't
> realize it sucked that bad.  Is there a preference for running
> threads at the head of the list (like UNIX, circa 1979) or
> something like that?
>
>   (And yes, I know about "multiprocessing".  These threads are already
> in one of several service processes.  I don't want to launch even more
> copies of the Python interpreter.  The threads are usually I/O bound,
> but when they hit unusually long web pages, they go compute-bound
> during parsing.)
>
>   Setting "sys.setcheckinterval" from the default to 1 seems
> to have little effect.  This is on Windows 7.
>
>                                John Nagle
> --
> http://mail.python.org/mailman/listinfo/python-list
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: CPython thread starvation

[Roy Smith]

In article <7xy5pgqwto@ruckus.brouhaha.com>,
 Paul Rubin  wrote:

> John Nagle  writes:
> >I may do that to prevent the stall.  But the real problem was all
> > those DNS requests.  Parallizing them wouldn't help much when it took
> > hours to grind through them all.
> 
> True dat.  But building a DNS cache into the application seems like a
> kludge.  Unless the number of requests is insane, running a caching
> nameserver on the local box seems cleaner.

I agree that application-level name cacheing is "wrong", but sometimes 
doing it the wrong way just makes sense.  I could whip up a simple 
cacheing wrapper around getaddrinfo() in 5 minutes.  Depending on the 
environment (both technology and bureaucracy), getting a cacheing 
nameserver installed might take anywhere from 5 minutes to a few days to 
kicking a dead whale down the beach (if you need to involve your 
corporate IT department) to it just ain't happening (if you need to 
involve your corporate IT department).

Doing DNS cacheing correctly is non-trivial.  In fact, if you're 
building it on top of getaddrinfo(), it may be impossible, since I don't 
think getaddrinfo() exposes all the data you need (i.e. TTL values).  
But, doing a half-assed job of cache expiration is better than not 
expiring your cache at all.  I would suggest (from experience) that if 
you build a getaddrinfo() wrapper, you have cache entries time out after 
a fairly short time.  From the problem description, it sounds like using 
a 1-minute timeout would get 99% of the benefit and might keep you from 
doing some bizarre things.

PS -- I've also learned by experience that nscd can mess up.  If DNS 
starts doing stuff that doesn't make sense, my first line of attack is 
usually killing and restarting the local nscd.  Often enough, that 
solves the problem, and it rarely causes any problems that anybody would 
notice.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: why () is () and [] is [] work in other way?

[Kiuhnm]

On 4/27/2012 17:39, Adam Skutt wrote:

On Apr 27, 8:07 am, Kiuhnm  wrote:

Useful... maybe, conceptually sound... no.
Conceptually, NaN is the class of all elements which are not numbers,
therefore NaN = NaN.


NaN isn't really the class of all elements which aren't numbers.  NaN
is the result of a few specific IEEE 754 operations that cannot be
computed, like 0/0, and for which there's no other reasonable
substitute (e.g., infinity) for practical applications .

In the real world, if we were doing the math with pen and paper, we'd
stop as soon as we hit such an error. Equality is simply not defined
for the operations that can produce NaN, because we don't know to
perform those computations.  So no, it doesn't conceptually follow
that NaN = NaN, what conceptually follows is the operation is
undefined because NaN causes a halt.


Mathematics is more than arithmetics with real numbers. We can use FP 
too (we actually do that!). We can say that NaN = NaN but that's just an 
exception we're willing to make. We shouldn't say that the equivalence 
relation rules shouldn't be followed just because *sometimes* we break them.



This is what programming languages ought to do if NaN is compared to
anything other than a (floating-point) number: disallow the operation
in the first place or toss an exception.  Any code that tries such an
operation has a logic error and must be fixed.

However, when comparing NaN against floating point numbers, I don't
see why NaN == NaN returning false is any less conceptually correct
than any other possible result.  NaN's very existence implicitly
declares that we're now making up the rules as we go along, so we
might as well pick the simplest set of functional rules.

Plus, floating point numbers violate our expectations of equality
anyway, frequently in  surprising ways.  0.1 + 0.1 + 0.1 == 0.3 is
true with pen and paper, but likely false on your computer.


Maybe wrong expectations of equality, since 0.1 (the real number) is 
/not/ a floating point.
Don't confuse the representation of floating points with the floating 
point themselves.



 It's even
potentially possible to compare two floating point variables twice and
get different results each time[1]!


We should look at the specification and not the single implementations.


 As such, we'd have this problem
with defining equality even if NaN didn't exist.  We must treat
floating-point numbers as a special case in order to write useful
working programs.  This includes defining equality in a way that's
different from what works for nearly every other data type.

Adam

[1] Due to register spilling causing intermediate rounding.  This
could happen with the x87 FPU since the registers were 80-bits wide
but values were stored in RAM as 64-bits.  This behavior is less
common now, but hardly impossible.


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

Re: why () is () and [] is [] work in other way?

[Chris Angelico]

On Sat, Apr 28, 2012 at 9:26 PM, Kiuhnm
 wrote:
> Your problem is that you think that copy semantics requires real copying. I
> really don't see any technical difficulty in virtualizing the all thing.

"Copy semantics" without "real copying" is an optimization that a
program should never need to be aware of. For instance, you could have
two 16GB strings share their buffers to avoid having to use 32GB of
memory; but to demonstrate copy semantics, they would need to
copy-on-write in some fashion. There's duplicate state but shared
memory. The trouble with duplicating state of a std::fstream is that
it's roughly impossible. You could perhaps simulate it with read-only
file access, but when you write, somehow it has to affect the disk,
and that means either you copy the file (but keep the same file name)
or have both of them affect the same file (meaning we're on Borg
semantics, not copying).

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

Re: solutions books

[ali deli]

Hi,




I'am a college physics student.




If you have the following document "

SOLUTIONS MANUAL
  TO FUNDAMENTALS OF ENGINEERING ELECTROMAGNETICS, by

DAVID CHENG ",




Could you please send me the document?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: why () is () and [] is [] work in other way?

[Kiuhnm]

On 4/27/2012 19:15, Adam Skutt wrote:

On Apr 27, 11:01 am, Kiuhnm  wrote:

On 4/27/2012 1:57, Adam Skutt wrote:

On Apr 26, 6:34 pm, Kiuhnmwrote:

If you

understand that your 'a' is not really an object but a reference to it,
everything becomes clear and you see that '==' always do the same thing.



Yes, object identity is implemented almost? everywhere by comparing
the value of two pointers (references)[1]. I've already said I'm not
really sure how else one would go about implementing it.



You might tell me that that's just an implementation detail, but when an
implementation detail is easier to understand and makes more sense than
the whole abstraction which is built upon it, something is seriously wrong.



I'm not sure what abstraction is being built here.  I think you have
me confused for someone else, possibly Steven.


The abstraction is this:
- There are primitives and objects.
- Primitives are not objects. The converse is also true.
- Primitives can become objects (boxing).
- Two primitives x and y are equal iff x == y.
- Two objects x and y are equal iff x.equals(y).
- Two objects are the same object iff x == y.
- If x is a primitive, then y = x is a deep copy.
- If x is an object, then y = x is a shallow copy.
- ...



This is not an abstraction at all, but merely a poor explanation of
how things work in Java.  Your last statement is totally incorrect, as
no copying of the object occurs whatsoever.  The reference is merely
reseated to refer to the new object. If you're going to chide me for
ignoring the difference between the reference and the referent object,
then you shouldn't ignore it either, especially in the one case where
it actually matters!  If we try to extend this to other languages,
then it breaks down completely.


With shallow copy I meant exactly that. I didn't think that my using the 
term with a more general meaning would cause such a reaction.

I don't agree on the other things you said, of course.




The truth:
- Primitives can be references.
- Two primitives are equal iff x == y.
- Operator '.' automatically derefences references.



You have the first statement backwards.  References are a primitive
construct, not the other way around.


So you're saying that I said that "Primitive constructs are references". 
Right...



 While true, it's still a bad way
to think about what's going on.  It breaks down once we add C++ /
Pascal reference types to the mix, for example.


?


It's better to think about variables (names) and just recognize that
not all variables have the same semantics.  It avoids details that are
irrelevant to writing actual programs and remains consistent.


Maybe in your opinion. As I said, I don't agree with you.


Equality or equivalence is a relation which is:
- reflexive
- symmetric
- transitive
Everything else... is something else. Call it semi-equality,
tricky-equality or whatever, but not equality, please.


Sure, but then it's illegal to allow the usage of '==' with floating
point numbers, which will never have these properties in any usable
implementation[1].


???


 So we're back to what started this tangent, and we
end up needing 'equals()' methods on our classes to distinguish
between the different forms of equality.  That's precisely what you
want to avoid.

Or we can just accept that '==' doesn't always possess those
properties, which is what essentially every programming language does,
and call it (value) equality.  As long as we don't cross incompatible
meanings, it's hard to believe that this isn't the right thing to do.




If anything, you have that backwards.  Look at Python: all variables
in Python have pointer semantics, not value semantics.


When everything is "white", the word "white" becomes redundant.
So the fact that everything in Python have reference semantics means
that we can't stop thinking about value and reference semantics.


Nope. The behavior of variables is absolutely essential to writing
correct programs.  If I write a program in Python that treats
variables as if they were values, it will be incorrect.


You misunderstood what I said. You wouldn't treat variables as if they 
were values because you wouldn't even know what that means and that 
that's even a possibility.
I've never heard an old C programmer talk about "value semantics" and 
"reference semantics". When everything is a value, your world is pretty 
simple.



  In imperative
languages, pointers have greater utility over value types because not
all types can obey the rules for value types.  For example, I don't
know how to give value semantics to something like a I/O object (e.g,
file, C++ fstream, C FILE), since I don't know how to create
independent copies.


By defining a copy constructor.


Then write me a working one.  I'll wait. To save yourself some time,
you can start with std::fstream.


Will you pay me for my time?

Your problem is that you think that copy semantics requires real 
copying. I really don't see any technical difficulty in 

Re: syntax for code blocks

[Kiuhnm]

On 4/27/2012 18:07, Steven D'Aprano wrote:
> On Fri, 27 Apr 2012 17:03:19 +0200, Kiuhnm wrote:
> 
>> On 4/27/2012 16:09, Steven D'Aprano wrote:
>>> On Fri, 27 Apr 2012 13:24:35 +0200, Kiuhnm wrote:
>>>
 I'd like to change the syntax of my module 'codeblocks' to make it
 more pythonic.

 Current Syntax:

with res<<  func(arg1)<<  'x, y':
print(x, y)

with res<<  func(arg1)<<  block_name<<  'x, y':
print(x, y)
>>>
>>>
>>> I'm sorry, I don't see how this is a code block. Where is the code in
>>> the block, and how can you pass it to another object to execute it?
>>
>> Maybe if you read the entire post...
> 
> No, I read the entire post. It made no sense to me. Let me give one
> example. You state:
> 
>  The full form is equivalent to
>   def anon_func(x, y):
>   print(x, y)
>   res = func(arg1, block_name = anon_func)
> 
> but this doesn't mean anything to me. What's func? Where does it come
> from? What's arg1? Why does something called block_NAME have a default
> value of a function instead of a NAME?
> 
> How about you give an actual working example of what you mean by a code
> block and how you use it?

The rewriting rules are the following, where X ---> Y means that X is rewritten 
as Y on the fly:

1)
  with res << func(args) << 'x, y':
  

  --->

  def anon_func(x, y):
  
  res = func(args, anon_func)

2)
  with res << func(args) << block_name << 'x, y':
  

  --->

  def anon_func(x, y):
  
  res = func(args, block_name = anon_func)

That's all.
func is some function which takes a function as a positional argument or as a 
keyword parameter neamed block_name.

Some examples:

1)
  text = "Anyone should be able to read this message!"
  with ris << re.sub(r'(\w)(\w+)(\w)', string = text) << repl << 'm':
  inner_word = list(m.group(2))
  random.shuffle(inner_word)
  _return (m.group(1) + "".join(inner_word) + m.group(3))
  print(ris)

which prints (something like):

  Aynnoe shluod be albe to read tihs msgseae!

2)
  numbers = [random.randint(1, 100) for i in range(30)]

  with sorted1 << sorted(numbers) << key << 'x':
  if x <= 50:
  _return(-x)
  else:
  _return(x)

  print(sorted1)

which prints (something like):
  [50, 47, 46, 28, 28, 25, 24, 23, 21, 19, 16, 15, 14, 3, 52, 52, 53, 54, 58, 
62,
63, 69, 70, 72, 74, 78, 84, 86, 90, 97]

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