Re: from future import pass_function

On 7/26/2012 4:48 PM, John Ladasky wrote: I had very similar thoughts about eight months ago, and posted them here: https://groups.google.com/forum/?fromgroups#!topic/comp.lang.python/CB_5fek2b8A I'm no computer science guru, but the idea that pass should be a function rather than a statement

Re: Generating valid identifiers

On Thu, 26 Jul 2012 13:28:26 -0600, Ian Kelly wrote: > The odds of a given pair of identifiers having the same digest to 10 hex > digits are 1 in 16^10, or approximately 1 in a trillion. Unless an attacker can select the field names, in which case they may be able to improve those odds significa

Re: pexcept module

On 07/25/2012 07:29 AM, Pritam Das wrote: > Is dere any good tutorial for pexcept module. > > As far as I can tell, there's no such module in the standard library. If you're talking about some 3r4 party product, it'd be polite to specify which one. Try: http://pexpect.sourceforge.net/pexpect.h

Re: ANN: dbf.py 0.94.003

On 27/07/12 05:31, Ethan Furman wrote: A few more bug fixes, and I actually included the documentation this time. :) It can be found at http://python.org/pypi/dbf, and has been tested on CPythons 2.4 - 2.7, and PyPy 1.8. [snip] Ethan, That's great. Can you comment on the ultimate aim of th

Re: pexcept module

On 25/07/2012 12:29, Pritam Das wrote: Is dere any good tutorial for pexcept module. google and ye shall find. Regards, Pritam Das -- Cheers. Mark Lawrence. -- http://mail.python.org/mailman/listinfo/python-list

Re: from future import pass_function

On 26/07/2012 18:19, Prasad, Ramit wrote: No offence to all the well meaning participants here, but this looks like trolling I thought Ranting Rick had sole dominion over trolling? Incorrect. Yes he can be a PITA but when he writes about tkinter/idle he appears to know what he's talking ab

Re: from future import pass_function

On 26/07/2012 18:33, Chris Angelico wrote: On Fri, Jul 27, 2012 at 3:19 AM, Prasad, Ramit wrote: No offence to all the well meaning participants here, but this looks like trolling I thought Ranting Rick had sole dominion over trolling? Certainly not. We are well endowed with trolls here (X

codecs.register_error for "strict", unicode.encode() and str.decode()

Hello, I think I'm missing some piece here. I'm trying to register a default error handler for handling exceptions for preventing encoding/decoding errors (I know how this works and that making this global is probably not a good practice, but I found this strange behaviour while writing a proof of

Re: from future import pass_function

John Ladasky wrote: I had very similar thoughts about eight months ago, and posted them here: https://groups.google.com/forum/?fromgroups#!topic/comp.lang.python/CB_5fek2b8A I'm no computer science guru, but the idea that pass should be a function rather than a statement continues to appeal to

Re: from future import pass_function

On Thursday, July 26, 2012 2:23:02 PM UTC-7, Ethan Furman wrote: > That's a reasonable thing to want, and quite easily accomplished by > passing `lambda: None` or `lambda *args, **kwargs: None` instead. That's the same solution that Steven D'Aprano proposed the last time we had this discussion

Re: from future import pass_function

John Ladasky wrote: On Wednesday, July 25, 2012 9:32:33 PM UTC-7, Ethan Furman wrote: 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. When I brought up thi

Re: from future import pass_function

In case the rest of the email didn't make it obvious, everything you quoted me on was sarcasm. I know those things can't be done, and I explained why they can't and shouldn't be done. Michael On Thu, Jul 26, 2012 at 5:16 AM, Devin Jeanpierre wrote: > On Thu, Jul 26, 2012 at 1:20 AM, Michael Hri

Re: dict: keys() and values() order guaranteed to be same?

Steven D'Aprano wrote: Python's promise is much stronger than merely "deterministic": while it does not promise what order the keys will be returned, it does promise that whatever that order turns out to be, they will returned in the same order as the matching values (unless you modify the dict

Re: from future import pass_function

On Thu, Jul 26, 2012 at 2:48 PM, John Ladasky wrote: > On Wednesday, July 25, 2012 1:40:45 AM UTC-7, 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

Re: from future import pass_function

It's not uncommon for "pass" to be referred to as a control statement, although I see your point that it isn't exerting as much control over the flow of execution as others. As further evidence, this doc categorizes it as a "statement" within "flow control tools": http://docs.python.org/tutorial/c

Re: dict: keys() and values() order guaranteed to be same?

On Thu, Jul 26, 2012 at 9:06 PM, Ethan Furman wrote: > Chris Angelico wrote: > >> On Tue, Jul 24, 2012 at 1:20 AM, Steven D'Aprano >> > >> wrote: >> >>> (Although if you think about the implementation of dicts as hash tables, >>> it does seem likely that it is trivial to enforce this -- one would

Re: dict: keys() and values() order guaranteed to be same?

Chris Angelico wrote: On Tue, Jul 24, 2012 at 1:20 AM, Steven D'Aprano wrote: (Although if you think about the implementation of dicts as hash tables, it does seem likely that it is trivial to enforce this -- one would have to work *harder* to break that promise than to keep it.) However, it

Re: from future import pass_function

On Wednesday, July 25, 2012 1:40:45 AM UTC-7, 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. I had

Re: from future import pass_function

On Wednesday, July 25, 2012 9:32:33 PM UTC-7, Ethan Furman wrote: > 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. When I brought up this same issue s

Re: Generating valid identifiers

On Thu, Jul 26, 2012 at 1:28 PM, Ian Kelly wrote: > The odds of a given pair of identifiers having the same digest to 10 > hex digits are 1 in 16^10, or approximately 1 in a trillion. If you > bought one lottery ticket a day at those odds, you would win > approximately once every 3 billion years.

ANN: dbf.py 0.94.003

A few more bug fixes, and I actually included the documentation this time. :) It can be found at http://python.org/pypi/dbf, and has been tested on CPythons 2.4 - 2.7, and PyPy 1.8. dbf v0.94.003 = dbf (also known as python dbase) is a module for reading/writing dBase III, FP,

Re: Generating valid identifiers

On Thu, Jul 26, 2012 at 9:30 AM, Steven D'Aprano wrote: > What happens if you get a collision? > > That is, you have two different long identifiers: > > a.b.c.d...something > a.b.c.d...anotherthing > > which by bad luck both hash to the same value: > > a.b.c.d.$AABB99 > a.b.c.d.$AABB99 > > (or wha

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

On Tue, Jul 24, 2012 at 9:07 PM, Ben Finney wrote: > +1 on celebrating τ day! https://www.youtube.com/watch?v=jG7vhMMXagQ> Also: http://tauday.com/ -- http://mail.python.org/mailman/listinfo/python-list

pexcept module

Is dere any good tutorial for pexcept module. Regards, Pritam Das Lead Engineer | pritam...@teledna.com | www.teledna.com M: +91-7278039994 | P: 080-1130 | F: 080-1132 ISO 9001:2008 Certified ---

Re: Python-list Digest, Vol 106, Issue 170

Ve.,zaxfaž Odeslzvané z telefonu HTC - Reply message - Od: python-list-requ...@python.org Komu: Předmět: Python-list Digest, Vol 106, Issue 170 Datum: čt, 7. 26, 2012 14:10 z-- http://mail.python.org/mailman/listinfo/python-list-- http://mail.python.org/mailman/listinfo/python-list

Re: from future import pass_function

On Thu, Jul 26, 2012 at 11:01 AM, Dennis Lee Bieber wrote: > On Thu, 26 Jul 2012 19:42:11 +1000, Chris Angelico > declaimed the following in gmane.comp.python.general: > > > > Well, if/while/for could be functions. So could with, probably. Now, > > def would be a little tricky... > > > An

Re: from future import pass_function

On Fri, Jul 27, 2012 at 4:01 AM, Dennis Lee Bieber wrote: > On Thu, 26 Jul 2012 19:42:11 +1000, Chris Angelico > declaimed the following in gmane.comp.python.general: > >> Well, if/while/for could be functions. So could with, probably. Now, >> def would be a little tricky... >> > And how

Re: Generating valid identifiers

* Would it be a problem to use CRC32 instead of SHA? (Since security is not a problem, and CRC32 is faster.) What happens if you get a collision? That is, you have two different long identifiers: a.b.c.d...something a.b.c.d...anotherthing which by bad luck both hash to the same value: a.b.c

Re: Generating valid identifiers

On 7/26/2012 5:26 AM Laszlo Nagy said... I have a program that creates various database objects in PostgreSQL. There is a DOM, and for each element in the DOM, a database object is created (schema, table, field, index and tablespace). I do not want this program to generate very long identifiers.

Re: from future import pass_function

On Fri, Jul 27, 2012 at 3:19 AM, Prasad, Ramit wrote: >> No offence to all the well meaning participants here, but this looks like >> trolling > > I thought Ranting Rick had sole dominion over trolling? Certainly not. We are well endowed with trolls here (Xah Lee isn't prolific, but is certainly

RE: from future import pass_function

> No offence to all the well meaning participants here, but this looks like > trolling I thought Ranting Rick had sole dominion over trolling? Ramit This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accura

Re: from future import pass_function

On Thu, Jul 26, 2012 at 11:21 AM, Steven D'Aprano wrote: > On Thu, 26 Jul 2012 13:45:23 +0200, Ulrich Eckhardt wrote: > >> I didn't say "Pass should be a function!" but asked "What do you >> think?". You are assuming lots of things about my goals and jumping to >> conclusions like that I'm complai

Re: Generating valid identifiers

Laszlo Nagy wrote: > I do not want this program to generate very long identifiers. It would > increase SQL parsing time, and don't look good. Let's just say that the > limit should be 32 characters. But I also want to recognize the > identifiers when I look at their modified/truncated names. Real

Re: Generating valid identifiers

On Thu, 26 Jul 2012 14:26:16 +0200, Laszlo Nagy wrote: > I do not want this program to generate very long identifiers. It would > increase SQL parsing time, Will that increase in SQL parsing time be more, or less, than the time it takes to generate CRC32 or SHA hashsums and append them to a trun

Re: from future import pass_function

On Thu, 26 Jul 2012 13:45:23 +0200, Ulrich Eckhardt wrote: > I didn't say "Pass should be a function!" but asked "What do you > think?". You are assuming lots of things about my goals and jumping to > conclusions like that I'm complaining about the stupid Python syntax, > that I'm a frustrated noo

Re: from future import pass_function

On Jul 25, 1:40 pm, 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(): >  

Re: Generating valid identifiers

On 7/26/2012 8:26 AM, Laszlo Nagy wrote: I have a program that creates various database objects in PostgreSQL. There is a DOM, and for each element in the DOM, a database object is created (schema, table, field, index and tablespace). I do not want this program to generate very long identifiers.

Re: ssl: add msg_callback

Hi, Thiébaud Weksteen weksteen.fr> writes: > > I wrote a patch for Python 3.2.3 to expose the function > SSL_CTX_set_msg_callback in the module _ssl. > [...] > > Let me know your opinion on that. Does it worth being included? Yes, it sounds useful. Your patch will have to be written against

Re: HMM and CRF Package

On Thursday, July 26, 2012 1:28:50 AM UTC+5:30, Terry Reedy wrote: > 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 inst

Re: from future import pass_function

On 7/26/2012 2:39 AM, Ulrich Eckhardt wrote: I have seen code that just created a list comprehension to iterate over something but was discarding the results. If you mean, discard the resulting list, that is probably bad code as it should not create the list in the first place. A generator ex

Re: append in IMAP4 from imaplib very slow

On 7/26/2012 7:55 AM, Simon Pirschel wrote: On 07/26/2012 11:25 AM, Simon Pirschel wrote: Ok, forget about the EXISTS and RECENT response. The server will response this way if you selected a mailbox, which I did in the Python code but not in the Perl code. I disabled selecting the mailbox in Pyt

Re: Generating valid identifiers

On 26 July 2012 13:26, Laszlo Nagy wrote: [...] > I do not want this program to generate very long identifiers. It would > increase SQL parsing time, and don't look good. Let's just say that the > limit should be 32 characters. But I also want to recognize the identifiers > when I look at their mo

Re: the meaning of r.......ïŸ

On 23.07.12 18:49, Steven D'Aprano wrote: ≤ for <= ≥ for >= I insist on the use of ⩽ and ⩾ too. -- http://mail.python.org/mailman/listinfo/python-list

Re: catch UnicodeDecodeError

On 07/26/2012 02:24 PM, Stefan Behnel wrote: > Read again: "*code* line". The OP was apparently failing to see that > the error did not originate in the source code lines that he had > wrapped with a try-except statement but somewhere else, thus leading to the misguided impression that the exceptio

Generating valid identifiers

I have a program that creates various database objects in PostgreSQL. There is a DOM, and for each element in the DOM, a database object is created (schema, table, field, index and tablespace). I do not want this program to generate very long identifiers. It would increase SQL parsing time, an

Re: catch UnicodeDecodeError

Philipp Hagemeister, 26.07.2012 14:17: > On 07/26/2012 01:15 PM, Stefan Behnel wrote: >>> exits with a UnicodeDecodeError. >> ... that tells you the exact code line where the error occurred. > > Which property of a UnicodeDecodeError does include that information? > > On cPython 2.7 and 3.2, I se

Re: from future import pass_function

Am 26.07.2012 11:26, schrieb Steven D'Aprano: On Thu, 26 Jul 2012 08:59:30 +0200, Ulrich Eckhardt wrote: Am 26.07.2012 04:38, schrieb Steven D'Aprano: (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()",

Re: catch UnicodeDecodeError

On 07/26/2012 01:15 PM, Stefan Behnel wrote: >> exits with a UnicodeDecodeError. > ... that tells you the exact code line where the error occurred. Which property of a UnicodeDecodeError does include that information? On cPython 2.7 and 3.2, I see only start and end, both of which refer to the nu

Re: catch UnicodeDecodeError

> that tells you the exact code line where the error occurred. No need to > look around. You are right: try: for line in f: do_something() except UnicodeDecodeError: do_something_different() does exactly what one would expect it to do. Thank you very much for pointing this out

Re: append in IMAP4 from imaplib very slow

On 07/26/2012 11:25 AM, Simon Pirschel wrote: Ok, forget about the EXISTS and RECENT response. The server will response this way if you selected a mailbox, which I did in the Python code but not in the Perl code. I disabled selecting the mailbox in Python and there is no difference in the runti

Re: catch UnicodeDecodeError

Jaroslav Dobrek, 26.07.2012 12:51: >>> try: >>> for line in f: # here text is decoded implicitly >>>do_something() >>> except UnicodeDecodeError(): >>> do_something_different() > > the code above (without the brackets) is semantically bad: The > exception is not caught. Sure it is

Re: catch UnicodeDecodeError

On Jul 26, 12:19 pm, wxjmfa...@gmail.com wrote: > On Thursday, July 26, 2012 9:46:27 AM UTC+2, Jaroslav Dobrek wrote: > > On Jul 25, 8:50 pm, Dave Angel wrote: > > > On 07/25/2012 08:09 AM, jaroslav.dob...@gmail.com wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > >

Re: catch UnicodeDecodeError

> And the cool thing is: you can! :) > > In Python 2.6 and later, the new Py3 open() function is a bit more hidden, > but it's still available: > >     from io import open > >     filename = "somefile.txt" >     try: >         with open(filename, encoding="utf-8") as f: >             for line in f:

Re: catch UnicodeDecodeError

On Thursday, July 26, 2012 9:46:27 AM UTC+2, Jaroslav Dobrek wrote: > On Jul 25, 8:50 pm, Dave Angel wrote: > > 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 > w

Re: from future import pass_function

On Thu, Jul 26, 2012 at 5:42 AM, Chris Angelico wrote: >> You omit the one control flow statement that could actually be turned >> into a function, raise. None of the rest could in Python (except >> class), and one of the rest couldn't in any language (def). > > Well, if/while/for could be functio

Re: catch UnicodeDecodeError

On Thu, Jul 26, 2012 at 5:46 PM, Jaroslav Dobrek wrote: > My problem is solved. What I need to do is explicitly decode text when > reading it. Then I can catch exceptions. I might do this in future > programs. Apologies if it's already been said (I'm only skimming this thread), but ISTM that you

Re: from future import pass_function

On Thu, Jul 26, 2012 at 7:16 PM, Devin Jeanpierre wrote: > On Thu, Jul 26, 2012 at 1:20 AM, Michael Hrivnak wrote: >> 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! > > No, you actual

Re: from future import pass_function

On Thu, 26 Jul 2012 08:59:30 +0200, Ulrich Eckhardt wrote: > Am 26.07.2012 04:38, schrieb Steven D'Aprano: >> The examples of pass-as-a-function shown by the Original Poster don't >> give any clue of what advantage there is to make pass a function. > > Just read the text, it just struck me how si

Re: append in IMAP4 from imaplib very slow

On 07/26/2012 09:49 AM, Simon Pirschel wrote: On 07/26/2012 05:21 AM, Tim Chase wrote: 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 appen

Re: from future import pass_function

On Thu, Jul 26, 2012 at 1:20 AM, Michael Hrivnak wrote: > 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! No, you actually can't. You omit the one control flow statement that could actu

Re: from future import pass_function

On Thu, 26 Jul 2012 08:39:25 +0200, Ulrich Eckhardt wrote: > I have seen code that just created a list comprehension to iterate over > something but was discarding the results. That could be a case for a "do > nothing" function. That would be a case for *not* using a list comprehension. Using a

Re: catch UnicodeDecodeError

Jaroslav Dobrek, 26.07.2012 09:46: > My problem is solved. What I need to do is explicitly decode text when > reading it. Then I can catch exceptions. I might do this in future > programs. Yes, that's the standard procedure. Decode on the way in, encode on the way out, use Unicode everywhere in be

Re: catch UnicodeDecodeError

On Jul 25, 8:50 pm, Dave Angel wrote: > 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 pr

Re: from future import pass_function

On 26/07/2012 06:20, Michael Hrivnak wrote: 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! And if we could persuade the BDFL to introduce braces, we could have {() and }() -- Cheer

Re: append in IMAP4 from imaplib very slow

On 07/26/2012 05:21 AM, Tim Chase wrote: 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

Re: from future import pass_function

On 26/07/2012 05:03, 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

Re: from future import pass_function

Am 26.07.2012 07:20, schrieb 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

Re: from future import pass_function

Am 26.07.2012 04:38, schrieb Steven D'Aprano: The examples of pass-as-a-function shown by the Original Poster don't give any clue of what advantage there is to make pass a function. Just read the text, it just struck me how similar pass and print are, i.e. that neither actually needs to be a k

Re: from future import pass_function

Am 25.07.2012 18:05, schrieb Chris Angelico: 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 w