Re: the meaning of rﾕ.......ï¾

[Mark Lawrence]

On 25/07/2012 07:43, Ben Finney wrote:

Mark Lawrence  writes:


Any civil engineers reading this who would find 22/7 perfectly
adequate for their task?


Civil engineering? Pffft, that deals with only a few orders of magnitude
range at most. “π is roughly 3” is usually good enough in that arena :-)



Love it.  I, personally, hereby take back everything adverse that anyone 
else may ever have written about you :)


--
Cheers.

Mark Lawrence.

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

from future import pass_function

[Ulrich Eckhardt]

Hi!

I just had an idea, it occurred to me that the pass statement is pretty 
similar to the print statement, and similarly to the print() function, 
there could be a pass() function that does and returns nothing.


Example:
   def pass():
   return

   try:
   do_something()
   except:
   pass()


One thing I don't like about this is the syntax

   class foo(object):
   pass()


What do you think?

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

Re: Python 2.6 StreamReader.readline()

[Walter Dörwald]

On 25.07.12 08:09, Ulrich Eckhardt wrote:


Am 24.07.2012 17:01, schrieb cpppw...@gmail.com:

 reader = codecs.getreader(encoding)
 lines  =  []
 with open(filename, 'rb') as f:
 lines  = reader(f, 'strict').readlines(keepends=False)

where encoding == 'utf-16-be'
Everything works fine, except that lines[0] is equal to
codecs.BOM_UTF16_BE
Is this behaviour correct, that the BOM is still present?


Yes, assuming the first line only contains that BOM. Technically it's a
space character, and why should those be removed?


If the first "character" in the file is a BOM the file encoding is 
probably not utf-16-be but utf-16.


Servus,
   Walter

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

Re: Python 2.6 StreamReader.readline()

[wxjmfauth]

On Wednesday, July 25, 2012 11:02:01 AM UTC+2, Walter Dörwald wrote:
> On 25.07.12 08:09, Ulrich Eckhardt wrote:
> 
> > Am 24.07.2012 17:01, schrieb cpppw...@gmail.com:
> >>  reader = codecs.getreader(encoding)
> >>  lines  =  []
> >>  with open(filename, 'rb') as f:
> >>  lines  = reader(f, 
> 'strict').readlines(keepends=False)
> >>
> >> where encoding == 'utf-16-be'
> >> Everything works fine, except that lines[0] is equal to
> >> codecs.BOM_UTF16_BE
> >> Is this behaviour correct, that the BOM is still present?
> >
> > Yes, assuming the first line only contains that BOM. Technically 
> it's a
> > space character, and why should those be removed?
> 
> If the first "character" in the file is a BOM the file encoding is 
> probably not utf-16-be but utf-16.
> 
> Servus,
> Walter

The byte order mark, if present, is nothing else than
an encoded 

>>> ud.name('\ufeff')
'ZERO WIDTH NO-BREAK SPACE'

*code point*.

Five "BOM" are possible (Unicode consortium). utf-8-sig, utf-16-be,
utf-16-le, utf-32-be, utf-32-le. The codecs module provide many
aliases.

The fact that utf-16/32 does correspond to -le or to -be may
vary according to the platforms, the compilers, ...

>>> sys.version
'3.2.3 (default, Apr 11 2012, 07:15:24) [MSC v.1500 32 bit
(Intel)]'
>>> codecs.BOM_UTF16_BE
b'\xfe\xff'
>>> codecs.BOM_UTF16_LE
b'\xff\xfe'
>>> codecs.BOM_UTF16
b'\xff\xfe'
>>>

---

As far as I know, Py 2.7 or Py 3.2 never return a "BOM" when
a file is read correctly.

>>> with open('a-utf-16-be.txt', 'r', encoding='utf-16-be') as f:
... r = f.readlines()
... for zeile in r:
... print(zeile.rstrip())
... 
abc
élève
cœur
€uro
>>> 


jmf

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

Re: from future import pass_function

[Philipp Hagemeister]

Unlike the print statement, pass has no overboarding complexity (like
>>, printing tuples, etc.) - it just serves as a marker (and
practicality beats purity).

And you don't ever want to use pass as a value (say, for map() or the
right side of an assignment). In fact, if pass were a function, users
could construct strange code like

x = pass()

def pass():
   raise Exception('Are you slacking off? Get back to work!')

And don't forget that while the parentheses mainly confuse users,
they're also making it harder to type, and feel like useless overhead
(similar to the parentheses in  if (x):  ). In fact, I'd argue that if
pass were a function, None would be the better placeholder:

try:
do_something()
except:
None # 2 hard-to-type (on a German keyboard) characters shorter
# (and probably way faster: No function call overhead and no need
#  to actually find out what pass happens to be in this context)

- Philipp


On 07/25/2012 10:40 AM, Ulrich Eckhardt wrote:
> Hi!
>
> I just had an idea, it occurred to me that the pass statement is pretty
> similar to the print statement, and similarly to the print() function,
> there could be a pass() function that does and returns nothing.
>
> Example:
>def pass():
>return
>
>try:
>do_something()
>except:
>pass()
>
>
> One thing I don't like about this is the syntax
>
>class foo(object):
>pass()
>
>
> What do you think?
>
> Uli



signature.asc
Description: OpenPGP digital signature
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: from future import pass_function

[Nicholas Cole]

On Wed, Jul 25, 2012 at 9:40 AM, Ulrich Eckhardt
 wrote:
> What do you think?
>

I enjoyed the question, but actually I don't think this is a good idea.

1.  If you really needed something like this, you could define it easily.

def do_nothing(*args, **keywords):
   return None

2. If it were a built-in function, you would be able to override it,
and then there would be chaos.

Best,

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

Re: reloading code and multiprocessing

[andrea crotti]

2012/7/23 Chris Angelico :
>
> That would probably be correct. However, I still think you may be
> fighting against the language instead of playing to its strengths.
>
> I've never fiddled with sys.modules like that, but I know some have,
> without problem.
>
> ChrisA
> --
> http://mail.python.org/mailman/listinfo/python-list


I would also like to avoid this in general, but we have many
subprocesses to launch and some of them might take weeks, so we need
to have a process which is always running, because there is never a
point in time where we can just say let's stop everything and start again..

Anyway if there are better solutions I'm still glad to hear them, but
I would also like to keep it simple..

Another thing which now we need to figure out is how to communicate
with the live process..  For example we might want to submit something
manually, which should pass from the main process.

The first idea is to have a separate process that opens a socket and
listens for data on a local port, with a defined protocol.

Then the main process can parse these commands and run them.
Are there easier ways otherwise?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: from future import pass_function

[Devin Jeanpierre]

On Wed, Jul 25, 2012 at 4:40 AM, Ulrich Eckhardt
 wrote:
> What do you think?

retort:

def foo():
None

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

catch UnicodeDecodeError

[jaroslav . dobrek]

Hello,

very often I have the following problem: I write a program that processes many 
files which it assumes to be encoded in utf-8. Then, some day, I there is a 
non-utf-8 character in one of several hundred or thousand (new) files. The 
program exits with an error message like this:

UnicodeDecodeError: 'utf8' codec can't decode byte 0xe4 in position 60: invalid 
continuation byte

I usually solve the problem by moving files around and by recoding them.

What I really want to do is use something like

try:
# open file, read line, or do something else, I don't care
except UnicodeDecodeError:
sys.exit("Found a bad char in file " + file + " line " + str(line_number)

Yet, no matter where I put this try-except, it doesn't work.

How should I use try-except with UnicodeDecodeError?

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

Re: from future import pass_function

[Steven D'Aprano]

On Wed, 25 Jul 2012 10:40:45 +0200, Ulrich Eckhardt wrote:

> Hi!
> 
> I just had an idea, it occurred to me that the pass statement is pretty
> similar to the print statement, 
[...]
> try:
> do_something()
> except:
> pass()

What's the point of this? If you intend to do nothing, why call a 
function instead?

There's a surprising amount of effort involved behind the scenes in 
calling a function. Python has to:

1) look up the function's name to get access to the function object
2) push any arguments onto the stack
3) determine the function object's type
4) look up its __call__ method
5) match the arguments (if any) with the parameter list (if any)
6) execute the function body
7) push the return result (None) onto the stack in case it's needed
8) and pop it off the stack.

Turning pass into a function instead of a statement would essentially 
take something that does *nothing at all* into something that 
(figuratively speaking) jumps up to its feet, runs around the room three 
times, and then sits back down again.


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

Re: catch UnicodeDecodeError

[Andrew Berg]

On 7/25/2012 6:05 AM, jaroslav.dob...@gmail.com wrote:
> What I really want to do is use something like
> 
> try:
> # open file, read line, or do something else, I don't care
> except UnicodeDecodeError:
> sys.exit("Found a bad char in file " + file + " line " + str(line_number)
> 
> Yet, no matter where I put this try-except, it doesn't work.
> 
> How should I use try-except with UnicodeDecodeError?
The same way you handle any other exception. The traceback will tell you
the exact line that raised the exception. It helps us help you if you
include the full traceback and give more detail than "it doesn't work".

-- 
CPython 3.3.0b1 | Windows NT 6.1.7601.17803
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: catch UnicodeDecodeError

[Philipp Hagemeister]

Hi Jaroslav,

you can catch a UnicodeDecodeError just like any other exception. Can
you provide a full example program that shows your problem?

This works fine on my system:


import sys
open('tmp', 'wb').write(b'\xff\xff')
try:
buf = open('tmp', 'rb').read()
buf.decode('utf-8')
except UnicodeDecodeError as ude:
sys.exit("Found a bad char in file " + "tmp")


Note that you cannot possibly determine the line number if you don't
know what encoding the file is in (and what EOL it uses).

What you can do is count the number of bytes with the value 10 before
ude.start, like this:

lineGuess = buf[:ude.start].count(b'\n') + 1

- Philipp

On 07/25/2012 01:05 PM, jaroslav.dob...@gmail.com wrote:
> it doesn't work



signature.asc
Description: OpenPGP digital signature
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: catch UnicodeDecodeError

[jaroslav . dobrek]

On Wednesday, July 25, 2012 1:35:09 PM UTC+2, Philipp Hagemeister wrote:
> Hi Jaroslav,
> 
> you can catch a UnicodeDecodeError just like any other exception. Can
> you provide a full example program that shows your problem?
> 
> This works fine on my system:
> 
> 
> import sys
> open('tmp', 'wb').write(b'\xff\xff')
> try:
> buf = open('tmp', 'rb').read()
> buf.decode('utf-8')
> except UnicodeDecodeError as ude:
> sys.exit("Found a bad char in file " + "tmp")
> 

Thank you. I got it. What I need to do is explicitly decode text.

But I think trial and error with moving files around will in most cases be 
faster. Usually, such a problem occurs with some (usually complex) program that 
I wrote quite a long time ago. I don't like editing old and complex programs 
that work under all normal circumstances.

What I am missing (especially for Python3) is something like:

try:
for line in sys.stdin:
except UnicodeDecodeError:
sys.exit("Encoding problem in line " + str(line_number))

I got the point that there is no such thing as encoding-independent lines. But 
if no line ending can be found, then the file simply has one single line. 
-- 
http://mail.python.org/mailman/listinfo/python-list

Dumping all the sql statements as backup

[andrea crotti]

I have some long running processes that do very long simulations which
at the end need to write things on a database.

At the moment sometimes there are network problems and we end up with
half the data on the database.

The half-data problem is probably solved easily with sessions and
sqlalchemy (a db-transaction), but still we would like to be able to
keep a backup SQL file in case something goes badly wrong and we want to
re-run it manually..

This might also be useful if we have to rollback the db for some reasons
to a previous day and we don't want to re-run the simulations..

Anyone did something similar?
It would be nice to do something like:

with CachedDatabase('backup.sql'):
# do all your things
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Dumping all the sql statements as backup

[Jack]

On 07/25/2012 09:56 AM, andrea crotti wrote:
> I have some long running processes that do very long simulations which
> at the end need to write things on a database.
>
> At the moment sometimes there are network problems and we end up with
> half the data on the database.
>
> The half-data problem is probably solved easily with sessions and
> sqlalchemy (a db-transaction), but still we would like to be able to
> keep a backup SQL file in case something goes badly wrong and we want to
> re-run it manually..
>
> This might also be useful if we have to rollback the db for some reasons
> to a previous day and we don't want to re-run the simulations..
>
> Anyone did something similar?
> It would be nice to do something like:
>
> with CachedDatabase('backup.sql'):
> # do all your things
>   
Since you know the content of what the sql code is, why not just build
the sql file(s) needed and store them so that in case of a burp you can
just execute the code file. If you don't know the exact sql code, dump
it to a file as the statements are constructed... The only problem you
would run into in this scenario is duplicate data, which is also easily
solvable by using transaction-level commits to the db.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Dumping all the sql statements as backup

[andrea crotti]

2012/7/25 Jack  Since you know the content of what the sql code is, why not just build
> the sql file(s) needed and store them so that in case of a burp you can
> just execute the code file. If you don't know the exact sql code, dump
> it to a file as the statements are constructed... The only problem you
> would run into in this scenario is duplicate data, which is also easily
> solvable by using transaction-level commits to the db.
> --
> http://mail.python.org/mailman/listinfo/python-list


Yes but how do I construct them with SqlAlchemy?
One possible option I found is to enable the logging of some parts of
SqlAlchemy, and use that log, (echo=True in create_engine does
something similar) but maybe there is a better option..

But I need to filter only the insert/update/delete probably..

And in general the processes have to run independently so in case of
database connection problems I would just let them retry until it
actually works.

When the transaction actually works then in the backed up log I can
add a marker(or archive the log), to avoid replaying it.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: HMM and CRF Package

[subhabangalore]

On Tuesday, July 24, 2012 9:09:02 PM UTC+5:30, (unknown) wrote:
> Dear Group,
> 
> I was looking for the following solutions.
> 
> (i) a Python Hidden Markov Model(HMM) library.
> (ii)a Python Conditional Random Field(CRF) library.
> (iii) I am using Python 3.2.1 on Windows 7(64 bit) and also like to get a 
> NLTK version.
> (iv) I may use unicode character as input.
> 
> If any one may kindly help me out. 
> 
> Best Regards,
> Subhabrata Banerjee.
> Gurgaon.
> India.

Dear Group,
I worked out a solution. As most of the libraries give so many bindings and 
conditions best way is to make it. Not very tough, I made earlier, but as some 
files were lost so was thinking instead of a remake if ready versions work.  Or 
may look change from Python 3 to previous version so when 3 will be supported 
solution. But can I install both Python 3 and Python2.x or call 2.x from 3.x?

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

Re: from future import pass_function

[Chris Angelico]

On Wed, Jul 25, 2012 at 6:40 PM, Ulrich Eckhardt
 wrote:
> I just had an idea, it occurred to me that the pass statement is pretty
> similar to the print statement, and similarly to the print() function, there
> could be a pass() function that does and returns nothing.
>
> Example:
>def pass():
>return
>
>try:
>do_something()
>except:
>pass()

Except that "pass" is a syntactic construct that basically says "hey,
I have an indented block here, but there's no code in it". It's not
executable any more than the syntactic token "INDENT" is. It's more
closely related to the colon at the end of "try" than it is to the
"do_something()" call.

By comparison, Python 2's print statement is executable. It causes
real action to happen at run-time. It makes sense to pass "print" as
an argument to something; for instance:

def some_generator():
   yield blah

map(print,some_generator())

Simple way of making the iterator display its yielded result. I cannot
imagine any circumstance in which you'd want to map "pass" over
everything. But then, as Teresa said, I'm only one, and possibly I'm
wrong!

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

Re: from future import pass_function

[Ethan Furman]

Ulrich Eckhardt wrote:
I just had an idea, it occurred to me that the pass statement is pretty 
similar to the print statement, and similarly to the print() function, 
there could be a pass() function that does and returns nothing.


Example:
   def pass():
   return

   try:
   do_something()
   except:
   pass()


Do you have a use case where `pass()` works but `pass` doesn't?

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

Re: from future import pass_function

[Devin Jeanpierre]

On Wed, Jul 25, 2012 at 12:05 PM, Chris Angelico  wrote:
> Simple way of making the iterator display its yielded result. I cannot
> imagine any circumstance in which you'd want to map "pass" over
> everything. But then, as Teresa said, I'm only one, and possibly I'm
> wrong!

True. But it might be nice to use pass both in lambdas and regular
functions, or to use pass as a variable name.

(Unfortunately, these two niceties are somewhat in conflict.)

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

append in IMAP4 from imaplib very slow

[Simon Pirschel]

Hi,

I'm currently experimenting with IMAP using Python 2.7.3 and IMAP4 from 
imaplib. I noticed the performance to be very bad. I read 5000 files 
from a directory and append them to an IMAP INBOX. The hole procedure of 
reading and appending is taking about 210 seconds.


I set up the exact same code in Perl to check if there is a general IMAP 
server configuration issue, since CPU and I/O isn't the problem. The 
same amount of data on the same IMAP server is done after 7.9 seconds 
using Perl.


The difference is huge and I tried to narrow the issue down by profiling 
the Python code.

The profile results are, 206 seconds are spent in calling socket.recv.

Python Code: http://pastebin.com/d2c9d4Dx
Profile Result: http://pastebin.com/rWCS8tAz
Perl Code: http://pastebin.com/ZV3Yv74d

Maybe someone can explain what's the problem, or help me debugging the 
issue.


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

Re: from future import pass_function

[Ian Kelly]

On Jul 25, 2012 10:51 AM, "Devin Jeanpierre"  wrote:

> True. But it might be nice to use pass both in lambdas and regular
> functions, or to use pass as a variable name.

You can already use pass (or the equivalent) in a lambda.

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

Re: from future import pass_function

[Devin Jeanpierre]

On Wed, Jul 25, 2012 at 2:14 PM, Ian Kelly  wrote:
> You can already use pass (or the equivalent) in a lambda.
>
> lambda: None

This lacks my foolish consistency.

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

Re: catch UnicodeDecodeError

[Dave Angel]

On 07/25/2012 08:09 AM, jaroslav.dob...@gmail.com wrote:
> On Wednesday, July 25, 2012 1:35:09 PM UTC+2, Philipp Hagemeister wrote:
>> Hi Jaroslav,
>>
>> you can catch a UnicodeDecodeError just like any other exception. Can
>> you provide a full example program that shows your problem?
>>
>> This works fine on my system:
>>
>>
>> import sys
>> open('tmp', 'wb').write(b'\xff\xff')
>> try:
>> buf = open('tmp', 'rb').read()
>> buf.decode('utf-8')
>> except UnicodeDecodeError as ude:
>> sys.exit("Found a bad char in file " + "tmp")
>>
> Thank you. I got it. What I need to do is explicitly decode text.
>
> But I think trial and error with moving files around will in most cases be 
> faster. Usually, such a problem occurs with some (usually complex) program 
> that I wrote quite a long time ago. I don't like editing old and complex 
> programs that work under all normal circumstances.
>
> What I am missing (especially for Python3) is something like:
>
> try:
> for line in sys.stdin:
> except UnicodeDecodeError:
> sys.exit("Encoding problem in line " + str(line_number))
>
> I got the point that there is no such thing as encoding-independent lines. 
> But if no line ending can be found, then the file simply has one single line. 

i can't understand your question.  if the problem is that the system
doesn't magically produce a variable called line_number, then generate
it yourself, by counting
in the loop.

Don't forget that you can tell the unicode decoder to ignore bad
characters, or to convert them to a specified placeholder.



-- 

DaveA

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

Re: HMM and CRF Package

[Terry Reedy]

On 7/25/2012 11:58 AM, subhabangal...@gmail.com wrote:
> As most of the libraries give so many bindings and conditions best way
is to make it. Not very tough, I made earlier, but as some files were
lost so was thinking instead of a remake if ready versions work.  Or may
look change from Python 3 to previous version so when 3 will be
supported solution. But can I install both Python 3 and Python2.x or
call 2.x from 3.x?

You can have multiple versions of Python installed. Just be careful on 
*nix to use altinstall so as to not disturb the system install used by 
the system.


Pythonx.y can only use code that works with x.y ;=). However, any Python 
process can use any other program via the subprocess module. You just 
have to work out the data transfer.


--
Terry Jan Reedy



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

Re: append in IMAP4 from imaplib very slow

[Antoine Pitrou]

Simon Pirschel  abusix.org> writes:
> 
> Hi,
> I'm currently experimenting with IMAP using Python 2.7.3 and IMAP4
> from imaplib. I noticed the performance to be very bad. I read 5000
> files from a directory and append them to an IMAP INBOX. The hole
> procedure of reading and appending is taking about 210 seconds.
> I set up the exact same code in Perl to check if there is a general
> IMAP server configuration issue, since CPU and I/O isn't the
> problem. The same amount of data on the same IMAP server is done
> after 7.9 seconds using Perl.
> The difference is huge and I tried to narrow the issue down by
> profiling the Python code.
> The profile results are, 206 seconds are spent in calling
> socket.recv.

This just means that most of the time is spent waiting for the server to
reply. Perhaps the Perl and Python IMAP libraries use different IMAP commands
for appending?

Regards

Antoine.


-- 
Software development and contracting: http://pro.pitrou.net


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

Re: from future import pass_function

[Ross Ridge]

Ulrich Eckhardt wrote:
> I just had an idea, it occurred to me that the pass statement is pretty
> similar to the print statement, 
[...]
> try:
> do_something()
> except:
> pass()

Steven D'Aprano   wrote:
>What's the point of this?

Remember everything you've said about why its a good thing the that
print statement is now a function?  That.

Ross Ridge

-- 
 l/  //   Ross Ridge -- The Great HTMU
[oo][oo]  rri...@csclub.uwaterloo.ca
-()-/()/  http://www.csclub.uwaterloo.ca/~rridge/ 
 db  //   
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: append in IMAP4 from imaplib very slow

[Tim Chase]

On 07/25/12 12:47, Simon Pirschel wrote:
> I'm currently experimenting with IMAP using Python 2.7.3 and
> IMAP4 from imaplib. I noticed the performance to be very bad. I
> read 5000 files from a directory and append them to an IMAP
> INBOX. The hole procedure of reading and appending is taking
> about 210 seconds.
> 
> I set up the exact same code in Perl to check if there is a
> general IMAP server configuration issue, since CPU and I/O isn't
> the problem. The same amount of data on the same IMAP server is
> done after 7.9 seconds using Perl.
> 
> The difference is huge and I tried to narrow the issue down by
> profiling the Python code. The profile results are, 206 seconds
> are spent in calling socket.recv.

While I don't know the ins and outs of the Perl code, it looks like
the Python imaplib.py is doing some pretty straight-forward
send/receive work.  However, IMAP4 does support both pipelining and
multi-append extensions, so if the Perl code takes advantage of the
features if the server offers them, it might be reaping significant
gains over the naïve Python code.

Can you get a debugging dump of the commands being sent each way?
(particularly if you see a bunch of APPEND commands before the reply
acknowledgement, as detailed at [1])

-tkc

[1]
http://www.ietf.org/rfc/rfc3502.txt on page 4

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

Re: from future import pass_function

[Ross Ridge]

Steven D'Aprano   wrote:
>What's the point of this?
 
Ross Ridge wrote:
> Remember everything you've said about why its a good thing the that
> print statement is now a function?  That.

Steven D'Aprano   wrote:
>I can't believe I actually have to point this out explicitly, but pass is 
>not print. Apart from them both starting with the letter "P", they are 
>nothing alike. There are good reasons for making print a function, and 
>they don't apply to pass because pass doesn't do what print does.

No, they're very much alike.  That's why all your arguments for print
as function also apply just as well to pass a function.  Your arguments
had very little to do what what print actually did.

Ross Ridge

-- 
 l/  //   Ross Ridge -- The Great HTMU
[oo][oo]  rri...@csclub.uwaterloo.ca
-()-/()/  http://www.csclub.uwaterloo.ca/~rridge/ 
 db  //   
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: from future import pass_function

[Chris Angelico]

On Thu, Jul 26, 2012 at 1:30 PM, Ross Ridge  wrote:
> Steven D'Aprano   wrote:
>>I can't believe I actually have to point this out explicitly, but pass is
>>not print. Apart from them both starting with the letter "P", they are
>>nothing alike. There are good reasons for making print a function, and
>>they don't apply to pass because pass doesn't do what print does.
>
> No, they're very much alike.  That's why all your arguments for print
> as function also apply just as well to pass a function.  Your arguments
> had very little to do what what print actually did.

Except that print / print() is executable. Execution proceeds through
your code, comes to a "print", and goes off to handle that, then comes
back to your code. But "pass" doesn't have code attached to it. Why
should it be a function?

One of the reasons for print becoming a function was its strange
collection of modifiers. How do you, with the print statement, send
output to someplace other than stdout? How do you make it not put a
newline? Far more logical to make those into keyword-only arguments to
a function, and far easier to later add more such options. What
parameters do you give to "pass"?

The pass keyword exists because Python can't have an empty pair of
braces, or an empty semicolon, to represent a "null statement". It
needs a keyword. That keyword is syntax, not code.

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

Re: from future import pass_function

[Ross Ridge]

Ross Ridge  wrote:
> No, they're very much alike.  That's why all your arguments for print
> as function also apply just as well to pass a function.  Your arguments
> had very little to do what what print actually did.

Chris Angelico   wrote:
>Except that print / print() is executable. Execution proceeds through
>your code, comes to a "print", and goes off to handle that, then comes
>back to your code. But "pass" doesn't have code attached to it. Why
>should it be a function?

For consistancy with print.  What it does doesn't matter any more than
what print did mattered.

Ross Ridge

-- 
 l/  //   Ross Ridge -- The Great HTMU
[oo][oo]  rri...@csclub.uwaterloo.ca
-()-/()/  http://www.csclub.uwaterloo.ca/~rridge/ 
 db  //   
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: from future import pass_function

[alex23]

On Jul 26, 11:42 am, Ross Ridge  wrote:
> Remember everything you've said about why its a good thing the that
> print statement is now a function?  That.

You regularly have the need to override the behaviour of pass?

Are you _really_ saying you see no distinction between an application-
level function and a low-level command directed at the interpreter?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: from future import pass_function

[alex23]

On Jul 26, 1:30 pm, Ross Ridge  wrote:
> No, they're very much alike.

Repetition isn't evidence. You keep making this claim, so support it.

> That's why all your arguments for print
> as function also apply just as well to pass a function.  Your arguments
> had very little to do what what print actually did.

As far as I can see, the only arguments Steven made were against pass
as a function, with an illustration of the function call cost that
pass-as-function would incur.

Your arguments, on the other hand, amount to nothing more than "nuh
uh!"
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: from future import pass_function

[Ethan Furman]

Ross Ridge wrote:

Ross Ridge  wrote:

No, they're very much alike.  That's why all your arguments for print
as function also apply just as well to pass a function.  Your arguments
had very little to do what what print actually did.


Chris Angelico   wrote:

Except that print / print() is executable. Execution proceeds through
your code, comes to a "print", and goes off to handle that, then comes
back to your code. But "pass" doesn't have code attached to it. Why
should it be a function?


For consistancy with print.  What it does doesn't matter any more than
what print did mattered.


Of course what print did mattered.  `print` was not changed to `print()` 
because a function looks cooler; it was changed because it does stuff, 
and what it does could be changed with parameters, and overriding it 
with your own custom thingie was a useful thing to do.


What code does `pass` run?  When do we pass parameters to `pass`?   When 
do we need to override `pass`?


Answers:  None.  Never.  Still waiting for a reply from the OP for a use 
case.


How does that quote go?  "A foolish consistency is the hobgoblin of 
little minds"?  This definitely fits that category.


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

Re: from future import pass_function

[Rusi]

Ulrich:
If you take a look at pep 3105 you find five rationales.
http://www.python.org/dev/peps/pep-3105/#rationale

If the first were the only one then your suggestion would have merit.
There are also the other 4 in which pass and print dont really
correspond.

Steven wrote earlier:
> I have an axe that has been passed down for generations through my
> family, from my father, his father before him, and his father, and his
> father before him. Occasionally we replace the handle, or put on a new
> head, but that axe is almost as good as the day my great-great-
> grandfather made it.

Yeah I see that you are always wielding your great-great-grandfather's
axe. As for example

On Jul 26, 7:38 am, Steven D'Aprano  wrote:
> (Actually, I reckon that what is driving this idea is that the OP is a
> beginner, and he's got a syntax error a few times from writing "pass()",
> and so he thought it would be easier to force other people to change tens
> or hundreds of thousands of Python programs to use "pass()" instead of
> "pass" than to just learn to stop putting parentheses after it. I
> remember what it was like to be a beginner with six weeks experience in a
> twenty year old language, full of shiny new ideas for "improving" it.)


Do you sharpen it sometimes?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: from future import pass_function

[Michael Hrivnak]

If we want pass(), then why not break() and continue()?  And also
def() and class()?  for(), while(), if(), with(), we can make them all
callable objects!

Except that they are control statements.  They are not objects, they
have no type, and they can never be evaluated in an expression.  And
most importantly, there is no value to be gained by making them
objects.

It is valuable for a language to have control statements, as others
have already explained.  This is an interesting exercise to think
about what their nature is, but at the end of the day, embrace them
for what they are.

Michael

On Wed, Jul 25, 2012 at 4:40 AM, Ulrich Eckhardt
 wrote:
> Hi!
>
> I just had an idea, it occurred to me that the pass statement is pretty
> similar to the print statement, and similarly to the print() function, there
> could be a pass() function that does and returns nothing.
>
> Example:
>def pass():
>return
>
>try:
>do_something()
>except:
>pass()
>
>
> One thing I don't like about this is the syntax
>
>class foo(object):
>pass()
>
>
> What do you think?
>
> Uli
> --
> http://mail.python.org/mailman/listinfo/python-list
-- 
http://mail.python.org/mailman/listinfo/python-list

ssl: add msg_callback

[Thiébaud Weksteen]

Hi python-list,

I wrote a patch for Python 3.2.3 to expose the function
SSL_CTX_set_msg_callback in the module _ssl.

I was actually surprise this function was not already in the
standard library as it is really handy:
"SSL_CTX_set_msg_callback() or SSL_set_msg_callback() can be used
to define a message callback function cb for observing all SSL/TLS
protocol messages (such as handshake messages) that are received or 
sent."


Here is the patch:
https://github.com/tweksteen/abrupt-usecase/blob/master/python-ssl-3.2.3.patch

Let me know your opinion on that. Does it worth being included?

Thiébaud

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

Re: ssl: add msg_callback

[Chris Rebert]

On Wed, Jul 25, 2012 at 8:47 PM, Thiébaud Weksteen 
wrote:
>
> Hi python-list,
>
> I wrote a patch for Python 3.2.3 to expose the function
> SSL_CTX_set_msg_callback in the module _ssl.
>
> I was actually surprise this function was not already in the
> standard library as it is really handy:

Well, the underscore in the module name indicates that such modules
are private implementation details, hence why _ssl is undocumented.

> "SSL_CTX_set_msg_callback() or SSL_set_msg_callback() can be used
> to define a message callback function cb for observing all SSL/TLS
> protocol messages (such as handshake messages) that are received or sent."
>
> Here is the patch:
>
> https://github.com/tweksteen/abrupt-usecase/blob/master/python-ssl-3.2.3.patch
>
> Let me know your opinion on that. Does it worth being included?

python-dev would probably be the best place to ask, since they have
the ultimate say on whether to accept your patch:
http://mail.python.org/mailman/listinfo/python-dev/
and/or you can file a bug in the tracker with your patch attached:
http://bugs.python.org/

On the face of it, the feature sounds fairly useful for debugging.

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