[RELEASE] Python 3.13.5 is now available (yes, really...)

When I was younger (...hush) we would call this a brown paper bag release, but actually, we shouldn’t hide from our mistakes. We’re only human. So, please enjoy: <https://discuss.python.org/t/python-3-13-5-is-now-available-yes-really/95211#p-254481-python-3135-1>Python 3.13.5

Re: "Invalid literal for int() with base 10": is it really a literal?

Chris Angelico wrote at 2023-5-26 18:29 +1000: > ... >However, if you want to change the wording, I'd be more inclined to >synchronize it with float(): > float("a") >Traceback (most recent call last): > File "", line 1, in >ValueError: could not convert string to float: 'a' +1 -- https://m

RE: "Invalid literal for int() with base 10": is it really a literal?

valid literal for int() with base 10": is it really a literal? Kevin M. Wilson's post "Invalid literal for int() with base 10?" got me thinking about the use of the word "literal" in that message. Is it correct to use "literal" in that context? It's c

Re: "Invalid literal for int() with base 10": is it really a literal?

On 2023-05-26 09:29, Chris Angelico wrote: On Fri, 26 May 2023 at 17:56, Roel Schroeven wrote: Kevin M. Wilson's post "Invalid literal for int() with base 10?" got me thinking about the use of the word "literal" in that message. Is it correct to use "literal" in that context? It's correct in s

Re: "Invalid literal for int() with base 10": is it really a literal?

and creative and with any luck you can make a career out of it; 3) anything that gets invented after you’re thirty is against the natural order of things and the beginning of the end of civilisation as we know it until it’s been around for about ten years when it gradually turns out to be a

Re: "Invalid literal for int() with base 10": is it really a literal?

On Fri, 26 May 2023 at 17:56, Roel Schroeven wrote: > > Kevin M. Wilson's post "Invalid literal for int() with base 10?" got me > thinking about the use of the word "literal" in that message. Is it > correct to use "literal" in that context? It's correct in something like > this: > > >>> int('inv

"Invalid literal for int() with base 10": is it really a literal?

Kevin M. Wilson's post "Invalid literal for int() with base 10?" got me thinking about the use of the word "literal" in that message. Is it correct to use "literal" in that context? It's correct in something like this: >>> int('invalid') Traceback (most recent call last):   File "", line 1, in

Re: imaplib: is this really so unwieldy?

On Sun, May 30, 2021 at 1:04 AM hw wrote: > > On 5/28/21 2:36 AM, boB Stepp wrote: > > > > Just as SMTP is the protocol for sending email, the Internet Message > > Access Protocol (IMAP) specifies how to communicate with an email > > provider’s server to retrieve emails sent to your email addres

Re: imaplib: is this really so unwieldy?

On 5/28/21 2:36 AM, boB Stepp wrote: On Thu, May 27, 2021 at 6:22 PM Cameron Simpson wrote: On 27May2021 18:42, hw wrote: So it seems that IMAP support through python is virtually non-existent. This still sureprises me, but I've not tried to use IMAP seriously. I read email locally, and

Re: string storage [was: Re: imaplib: is this really so unwieldy?]

Il 27/05/2021 05:54, Cameron Simpson ha scritto: On 26May2021 12:11, Jon Ribbens wrote: On 2021-05-26, Alan Gauld wrote: I confess I had just assumed the unicode strings were stored in native unicode UTF8 format. If you do that then indexing and slicing strings becomes very slow. True, bu

Re: imaplib: is this really so unwieldy?

On Thu, May 27, 2021 at 6:22 PM Cameron Simpson wrote: > > On 27May2021 18:42, hw wrote: > >So it seems that IMAP support through python is virtually non-existent. > > This still sureprises me, but I've not tried to use IMAP seriously. I > read email locally, and collect it with POP instead. Wit

Re: imaplib: is this really so unwieldy?

nd wonderful things depending what you ask it for, this particular library (a) does not parse the search field parameter ('(UID)') or the responses. It passes them through and 9b) correspondingly does not interpret the result beyond unpacking the IMAP response into the data packets provid

Re: imaplib: is this really so unwieldy?

On 5/25/21 3:55 PM, Grant Edwards wrote: On 2021-05-25, hw wrote: I'm about to do stuff with emails on an IMAP server and wrote a program using imaplib My recollection of using imaplib a few years ago is that yes, it is unweildy, oddly low-level, and rather un-Pythonic (excuse my presumption

Re: imaplib: is this really so unwieldy?

each kind of like a library in their own right. The if __name__=="__main__" idiom is really handy for this. It lets me build testing into each module. If I run the module directly, it can execute tests on the functions in that module. If it's imported, the code inside the if __name__=

Re: imaplib: is this really so unwieldy?

On Fri, May 28, 2021 at 4:04 AM Peter J. Holzer wrote: > > On 2021-05-26 08:34:28 +1000, Chris Angelico wrote: > > Yes, any given string has a single width, which makes indexing fast. > > The memory cost you're describing can happen, but apart from a BOM > > widening an otherwise-ASCII string to 1

Re: imaplib: is this really so unwieldy?

On 2021-05-26 08:34:28 +1000, Chris Angelico wrote: > Yes, any given string has a single width, which makes indexing fast. > The memory cost you're describing can happen, but apart from a BOM > widening an otherwise-ASCII string to 16-bit, there aren't many cases > where you'll get a single wide ch

Re: imaplib: is this really so unwieldy?

it do something with a particular message by uid? So it's all guesswork, and I gave up after a while and programmed what I wanted in perl. The documentation of this library sucks, and there are worlds between it and the documentation for the libraries I used with perl. I think you're better

Re: string storage [was: Re: imaplib: is this really so unwieldy?]

On Thu, May 27, 2021 at 1:56 PM Cameron Simpson wrote: > > On 26May2021 12:11, Jon Ribbens wrote: > >On 2021-05-26, Alan Gauld wrote: > >> I confess I had just assumed the unicode strings were stored > >> in native unicode UTF8 format. > > > >If you do that then indexing and slicing strings beco

Re: string storage [was: Re: imaplib: is this really so unwieldy?]

On 26May2021 12:11, Jon Ribbens wrote: >On 2021-05-26, Alan Gauld wrote: >> I confess I had just assumed the unicode strings were stored >> in native unicode UTF8 format. > >If you do that then indexing and slicing strings becomes very slow. True, but that isn't necessarily a show stopper. My im

Re: string storage [was: Re: imaplib: is this really so unwieldy?]

On 26/05/2021 22:15, Tim Chase wrote: > If you don't decode it upon reading it in, it should still be 100MB > because it's a stream of encoded bytes. I usually convert them to utf8. > You don't specify what you then do with this humongous string, Mainly I search for regex patterns which can

Re: string storage [was: Re: imaplib: is this really so unwieldy?]

On 2021-05-26 18:43, Alan Gauld via Python-list wrote: > On 26/05/2021 14:09, Tim Chase wrote: >>> If so, doesn't that introduce a pretty big storage overhead for >>> large strings? >> >> Yes. Though such large strings tend to be more rare, largely >> because they become unweildy for other reas

Re: string storage [was: Re: imaplib: is this really so unwieldy?]

On 26/05/2021 14:09, Tim Chase wrote: >> If so, doesn't that introduce a pretty big storage overhead for >> large strings? > > Yes. Though such large strings tend to be more rare, largely because > they become unweildy for other reasons. I do have some scripts that work on large strings - mainl

Re: string storage [was: Re: imaplib: is this really so unwieldy?]

On 5/26/2021 12:07 PM, Chris Angelico wrote: On Thu, May 27, 2021 at 1:59 AM Jon Ribbens via Python-list wrote: On 2021-05-26, Alan Gauld wrote: On 25/05/2021 23:23, Terry Reedy wrote: In CPython's Flexible String Representation all characters in a string are stored with the same number of

Re: string storage [was: Re: imaplib: is this really so unwieldy?]

On Thu, May 27, 2021 at 1:59 AM Jon Ribbens via Python-list wrote: > > On 2021-05-26, Alan Gauld wrote: > > On 25/05/2021 23:23, Terry Reedy wrote: > >> In CPython's Flexible String Representation all characters in a string > >> are stored with the same number of bytes, depending on the largest >

Re: string storage [was: Re: imaplib: is this really so unwieldy?]

On 2021-05-26, Alan Gauld wrote: > On 25/05/2021 23:23, Terry Reedy wrote: >> In CPython's Flexible String Representation all characters in a string >> are stored with the same number of bytes, depending on the largest >> codepoint. > > I'm learning lots of new things in this thread! > > Does th

exit() builtin, was Re: imaplib: is this really so unwieldy?

On 26/05/2021 01:02, Cameron Simpson wrote: On 25May2021 15:53, Dennis Lee Bieber wrote: On Tue, 25 May 2021 19:21:39 +0200, hw declaimed the following: Oh ok, it seemed to be fine. Would it be the right way to do it with sys.exit()? Having to import another library just to end a program mi

Re: string storage [was: Re: imaplib: is this really so unwieldy?]

On 2021-05-26 08:18, Alan Gauld via Python-list wrote: > Does that mean that if I give Python a UTF8 string that is mostly > single byte characters but contains one 4-byte character that > Python will store the string as all 4-byte characters? As best I understand it, yes: the cost of each "chara

Re: string storage [was: Re: imaplib: is this really so unwieldy?]

On Wed, May 26, 2021 at 10:04 PM Alan Gauld via Python-list wrote: > > On 25/05/2021 23:23, Terry Reedy wrote: > > > In CPython's Flexible String Representation all characters in a string > > are stored with the same number of bytes, depending on the largest > > codepoint. > > I'm learning lots of

string storage [was: Re: imaplib: is this really so unwieldy?]

On 25/05/2021 23:23, Terry Reedy wrote: > In CPython's Flexible String Representation all characters in a string > are stored with the same number of bytes, depending on the largest > codepoint. I'm learning lots of new things in this thread! Does that mean that if I give Python a UTF8 string

Re: imaplib: is this really so unwieldy?

On Wed, May 26, 2021 at 4:21 PM Grant Edwards wrote: > > On 2021-05-25, Dennis Lee Bieber wrote: > > >>Oh ok, it seemed to be fine. Would it be the right way to do it with > >>sys.exit()? Having to import another library just to end a program > >>might not be ideal. > > > > I've never had

Re: imaplib: is this really so unwieldy?

On 2021-05-25, Dennis Lee Bieber wrote: >>Oh ok, it seemed to be fine. Would it be the right way to do it with >>sys.exit()? Having to import another library just to end a program >>might not be ideal. > > I've never had to use sys. for exit... I would have sworn you used to have to im

Re: imaplib: is this really so unwieldy?

On 2021-05-25, Dennis Lee Bieber wrote: > On Tue, 25 May 2021 19:21:39 +0200, hw declaimed the > following: > > >> >>Oh ok, it seemed to be fine. Would it be the right way to do it with >>sys.exit()? Having to import another library just to end a program >>might not be ideal. > > I've n

Re: imaplib: is this really so unwieldy?

is an idicator that this is a bytes object being printed in a stringlike form because that is often a useful representation. Nothings inserting a "b" in the data itself. >and I have to keep asking myself what I'm looking at because bytes are >bytes. If you've got b&#x

Re: imaplib: is this really so unwieldy?

On 25May2021 15:53, Dennis Lee Bieber wrote: >On Tue, 25 May 2021 19:21:39 +0200, hw declaimed the >following: >>Oh ok, it seemed to be fine. Would it be the right way to do it with >>sys.exit()? Having to import another library just to end a program >>might not be ideal. > > I've never h

Re: imaplib: is this really so unwieldy?

On 26/05/21 5:21 am, hw wrote: On 5/25/21 11:38 AM, Cameron Simpson wrote: You'll need to import "sys". aving to import another library just to end a program might not be ideal. The sys module is built-in, so the import isn't really loading anything, it's ju

Re: imaplib: is this really so unwieldy?

th the same number of bytes, depending on the largest codepoint. >>> sys.getsizeof('\U0001') 80 >>> sys.getsizeof('\U0001'*2) 84 >>> sys.getsizeof('a\U0001') 84 Bytes in Python 3 are just a binary stream, which needs an enco

Re: imaplib: is this really so unwieldy?

On Wed, May 26, 2021 at 8:27 AM Grant Edwards wrote: > > On 2021-05-25, MRAB wrote: > > On 2021-05-25 16:41, Dennis Lee Bieber wrote: > > >> In Python 3, strings are UNICODE, using 1, 2, or 4 bytes PER > >> CHARACTER (I don't recall if there is a 3-byte version). If your > >> input bytes are all

Re: imaplib: is this really so unwieldy?

On 2021-05-25, MRAB wrote: > On 2021-05-25 16:41, Dennis Lee Bieber wrote: >> In Python 3, strings are UNICODE, using 1, 2, or 4 bytes PER >> CHARACTER (I don't recall if there is a 3-byte version). If your >> input bytes are all 7-bit ASCII, then they map directly to a 1-byte >> per character st

Re: imaplib: is this really so unwieldy?

. Bytes in Python 3 are just a binary stream, which needs an encoding to produce characters. Use the wrong encoding (say ISO-Latin-1) when the data is really UTF-8 will result in garbage. -- https://mail.python.org/mailman/listinfo/python-list

Re: imaplib: is this really so unwieldy?

ce of Unicode code points, and you translate to/from bytes if you need to work with bytes. Anyway, the IMAP response are bytes containing text. You get a lot of bytes. Well, ok, but it's not helpful that b is being inserted like everywhere, and I have to keep asking myself what I

Re: imaplib: is this really so unwieldy?

On 2021-05-25, hw wrote: > I'm about to do stuff with emails on an IMAP server and wrote a program > using imaplib My recollection of using imaplib a few years ago is that yes, it is unweildy, oddly low-level, and rather un-Pythonic (excuse my presumption in declaring what is and isn't "Pythoni

Re: imaplib: is this really so unwieldy?

> It's working (with Cyrus), but I have the feeling I'm doing it all wrong > because it seems so unwieldy. I have a program, Polly , which I wrote to generate XKCD 936 passphrases. (I got the idea - and the name - from Chris Angelico. See the README.) It builds

Re: imaplib: is this really so unwieldy?

On Tue, May 25, 2021 at 8:21 PM Cameron Simpson wrote: > When you go: > > text = str(data) > > that is _assuming_ a particular text encoding stored in the data. You > really ought to specify an encoding here. If you've not specified the > CHARSET for things, '

Re: imaplib: is this really so unwieldy?

tract text (strings) from bytes - the imaplib library may date from Python 2, where the str type was essentially a byte sequence. In Python 3 a str is a sequence of Unicode code points, and you translate to/from bytes if you need to work with bytes. Anyway, the IMAP response are bytes contai

imaplib: is this really so unwieldy?

Hi, I'm about to do stuff with emails on an IMAP server and wrote a program using imaplib which, so far, gets the UIDs of the messages in the inbox: #!/usr/bin/python import imaplib import re imapsession = imaplib.IMAP4_SSL('imap.example.com', port = 993) status, data = imapsession.login

Re: I was really uncomfort with any programming...

> I was really uncomfort with any programming,but I need to become efficient in python coding please give any tips to make interest in programming.hope your words will helpful to me.thank you Often the best way to make programming interesting is to use it to build something you care ab

Re: I really liked this Javscript FizzBuzz can it be as nice in Python?

On Sun, Apr 7, 2019 at 4:04 AM Dennis Lee Bieber wrote: > >output = "" > >for num in n: > >if (num % 3 == 0): output += "Fizz" > >if (num % 5 == 0): output += "Buzz" > >print(output or num) > > > You aren't initializing the output /inside/ the loop. > > Note that 0 is c

Re: I really liked this Javscript FizzBuzz can it be as nice in Python?

Wow in both of these examples I have no idea what is happening. Enjoying trying to figure it out :-) > print(*[[n,"Fizz","Buzz","Fizzbuzz"][int("300102100120100"[n%15])] for > n in range(1,101)], sep="\n") > This is not good code, and if anyone asks, I didn't say you were > allowed to do this

Re: I really liked this Javscript FizzBuzz can it be as nice in Python?

Sayth Renshaw wrote: > I saw this fizzbuzz in Eloquent Javascript and thought its really nice. > Not all the usual if else version, just if. > > for (let n = 1; n <= 100; n++) { > let output = ""; > if (n % 3 == 0) output += "Fizz"; > if (n

Re: I really liked this Javscript FizzBuzz can it be as nice in Python?

On 4/5/2019 2:52 AM, Sayth Renshaw wrote: for (let n = 1; n <= 100; n++) { n = range(100) n = range(1, 101) to cover 1 to 100 inclusive -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list

Re: I really liked this Javscript FizzBuzz can it be as nice in Python?

On Fri, Apr 5, 2019 at 5:56 PM Sayth Renshaw wrote: > > I saw this fizzbuzz in Eloquent Javascript and thought its really nice. Not > all the usual if else version, just if. > > for (let n = 1; n <= 100; n++) { > let output = ""; > if (n % 3 == 0) output +=

I really liked this Javscript FizzBuzz can it be as nice in Python?

I saw this fizzbuzz in Eloquent Javascript and thought its really nice. Not all the usual if else version, just if. for (let n = 1; n <= 100; n++) { let output = ""; if (n % 3 == 0) output += "Fizz"; if (n % 5 == 0) output += "Buzz"; console.log(output |

Re: Why don't we call the for loop what it really is, a foreach loop?

On Wed, 14 Sep 2016 22:01:34 -0700, Paul Rubin wrote: > Travis Griggs writes: >> for each in ['cake'] + ['eat', 'it'] * 2: >> print(each) > > https://pbs.twimg.com/media/Cr-edT2VUAArpVL.jpg the "Cowboy Song" buy Furrokh Bulsara -- Olmstead's Law: After all is said and do

Re: Why don't we call the for loop what it really is, a foreach loop?

Christian Gollwitzer writes: > http://www.azlyrics.com/lyrics/queen/bohemianrhapsody.html Alt version, https://www.youtube.com/watch?v=hpvlTVgeivU -- https://mail.python.org/mailman/listinfo/python-list

Re: Why don't we call the for loop what it really is, a foreach loop?

Christian Gollwitzer : > More interestingly, which language is it? First I thought C++ or Java, > but they don't use self and there is a => operator. PHP adornes > variables with $. Another C-derived language which has built-in hash > maps? C#. The => syntax is Python's lambda. Marko -- https:

Re: Why don't we call the for loop what it really is, a foreach loop?

Am 15.09.16 um 07:01 schrieb Paul Rubin: Travis Griggs writes: for each in ['cake'] + ['eat', 'it'] * 2: print(each) https://pbs.twimg.com/media/Cr-edT2VUAArpVL.jpg http://www.azlyrics.com/lyrics/queen/bohemianrhapsody.html More interestingly, which language is it? First I thou

Re: Why don't we call the for loop what it really is, a foreach loop?

Travis Griggs writes: > for each in ['cake'] + ['eat', 'it'] * 2: > print(each) https://pbs.twimg.com/media/Cr-edT2VUAArpVL.jpg -- https://mail.python.org/mailman/listinfo/python-list

Re: Why don't we call the for loop what it really is, a foreach loop?

> On Sep 13, 2016, at 13:57, rgrigo...@gmail.com wrote: > > It would help newbies and prevent confusion. for each in ['cake'] + ['eat', 'it'] * 2: print(each) -- https://mail.python.org/mailman/listinfo/python-list

Re: Why don't we call the for loop what it really is, a foreach loop?

On Tuesday, September 13, 2016 at 9:57:38 PM UTC+1, Richard Grigonis wrote: > It would help newbies and prevent confusion. I entirely agree. All together now "foreach is a jolly good fellow...". Kindest regards. Mark Lawrence. -- https://mail.python.org/mailman/listinfo/python-list

Re: Why don't we call the for loop what it really is, a foreach loop?

On Wed, 14 Sep 2016 06:57 am, rgrigo...@gmail.com wrote: > It would help newbies and prevent confusion. No it wouldn't. Claims-which-are-made-without-evidence-can-be-rejected-without-evidence-ly y'rs, -- Steve -- https://mail.python.org/mailman/listinfo/python-list

Re: Why don't we call the for loop what it really is, a foreach loop?

On 13/09/2016 22:20, Ian Kelly wrote: On Tue, Sep 13, 2016 at 2:57 PM, wrote: It would help newbies and prevent confusion. Ada uses "for". C++11 uses "for". Dart uses "for". Go uses "for". Groovy uses "for". Java uses "for". JavaScript uses "for". MATLAB uses "for". Objective-C uses "for". P

Re: Why don't we call the for loop what it really is, a foreach loop?

On 2016-09-13, Ian Kelly wrote: > On Tue, Sep 13, 2016 at 2:57 PM, wrote: >> It would help newbies and prevent confusion. > > Ada uses "for". [a dozen or so other langages] > Swift uses "for". > > Why do you think it's confusing that Python uses the same keyword in > its foreach loops that all t

Re: Why don't we call the for loop what it really is, a foreach loop?

On Tue, Sep 13, 2016 at 2:57 PM, wrote: > It would help newbies and prevent confusion. Ada uses "for". C++11 uses "for". Dart uses "for". Go uses "for". Groovy uses "for". Java uses "for". JavaScript uses "for". MATLAB uses "for". Objective-C uses "for". Pasceal uses "for". Perl moved from "fore

Re: Why don't we call the for loop what it really is, a foreach loop?

On Tue, Sep 13, 2016 at 4:57 PM, wrote: > It would help newbies and prevent confusion. Are you asking why Guido didn't call it foreach back in 1989, or why the core developers don't change it now, 27 years later? I can't speak for the historical perspective, but I'm sure there's basically no ch

Why don't we call the for loop what it really is, a foreach loop?

It would help newbies and prevent confusion. -- https://mail.python.org/mailman/listinfo/python-list

Re: Dictionary is really not easy to handle

I was overwhelmed that three gurus inspire me in three different ways in their own flavour:-) That's really appreciated! Now I understand why it's so, thanks to all of you. To Peter: > With that information, can you predict what > for k, v in {(1, 2): "three"}:

Re: Dictionary is really not easy to handle

On Thu, 28 Apr 2016 06:27 pm, jf...@ms4.hinet.net wrote: > I have a dictionary like this: > dct ={1: 'D', 5: 'A', 2: 'B', 3: 'B', 4: 'E'} > > The following code works: > for k in dct: print(k, dct[k]) > ... > 1 D > 2 B > 3 B > 4 E > 5 A When you iterate over the dictionary, you get a

Re: Dictionary is really not easy to handle

jf...@ms4.hinet.net wrote: > I have a dictionary like this: > dct ={1: 'D', 5: 'A', 2: 'B', 3: 'B', 4: 'E'} > > The following code works: > But...this one? > for k,v in dct: print(k,v) > ... > Traceback (most recent call last): > File "", line 1, in > TypeError: 'int' object is no

Re: Dictionary is really not easy to handle

On Thursday, April 28, 2016 at 1:57:40 PM UTC+5:30, jf...@ms4.hinet.net wrote: > I have a dictionary like this: > > >>> dct ={1: 'D', 5: 'A', 2: 'B', 3: 'B', 4: 'E'} > > The following code works: > > >>> for k in dct: print(k, dct[k]) > ... > 1 D > 2 B > 3 B > 4 E > 5 A > > and this one too: >

Dictionary is really not easy to handle

I have a dictionary like this: >>> dct ={1: 'D', 5: 'A', 2: 'B', 3: 'B', 4: 'E'} The following code works: >>> for k in dct: print(k, dct[k]) ... 1 D 2 B 3 B 4 E 5 A and this one too: >>> for k,v in dct.items(): print(k,v) ... 1 D 2 B 3 B 4 E 5 A But...this one? >>> for k,v in dct: print(k,v

Is your BI tool really intelligent ?

Is your #BI implementation ready to scale up for ALL of your future requirements? https://lnkd.in/ezeGr9b -- https://mail.python.org/mailman/listinfo/python-list

Re: iterating over strings seems to be really slow?

On Thu, Aug 28, 2014 at 6:53 AM, Rodrick Brown wrote: > def wc1(): > word="" > m={} > for c in s: > if c != " ": > word += c > else: > if m.has_key(word): > m[word] += 1 > else: > m[word] = 1 > word="" > > return(m) Your code is all buried behind HTML formatting, which makes it hard to read. But

Re: iterating over strings seems to be really slow?

On Wed, Aug 27, 2014 at 1:53 PM, Rodrick Brown wrote: def wc1(): > word="" > m={} > for c in s: > if c != " ": > word += c > else: > if m.has_key(word): > m[word] += 1 > else: > m[word] = 1 >

Re: iterating over strings seems to be really slow?

On 2014-08-27 16:53, Rodrick Brown wrote: > *I'm confused why the former function runs significantly faster when > wc1() builds the hash on a single pass and doesn't waste memory of > returning an array of strings? * > > *I would think wc2() to be slower what's going on here? * > > > #!/usr/bin/

iterating over strings seems to be really slow?

*I'm confused why the former function runs significantly faster when wc1() builds the hash on a single pass and doesn't waste memory of returning an array of strings? * *I would think wc2() to be slower what's going on here? * #!/usr/bin/env python s = "The black cat jump over the bigger black

Re: This formating is really tricky

On Wed, 27 Aug 2014 09:16:43 +0200, Peter Otten <__pete...@web.de> wrote: >Seymore4Head wrote: > >> On Mon, 25 Aug 2014 18:22:35 -0400, Terry Reedy >> wrote: >> >>>On 8/25/2014 4:14 PM, Seymore4Head wrote: import random sets=3 for x in range(0, sets): pb2=random.choice([

Re: This formating is really tricky

the help function, it is clear I will never get to about >> 90% of the features. >> >> Thanks >> > >That's why we keep telling you to FIRST go through a basic tutorial. It will >start at the >beginning and work up. You will really find you will learn the

Re: This formating is really tricky

Seymore4Head wrote: > On Mon, 25 Aug 2014 18:22:35 -0400, Terry Reedy > wrote: > >>On 8/25/2014 4:14 PM, Seymore4Head wrote: >>> import random >>> sets=3 >>> for x in range(0, sets): >>> pb2=random.choice([1-53]) >> >>You want random.randint(1, 53) >>... >>> alist = sorted([pb1, pb2, p

Re: This formating is really tricky

That's why we keep telling you to FIRST go through a basic tutorial. It will start at the beginning and work up. You will really find you will learn the language that way much MUCH faster than trying to pick things up piecemeal by asking totally isolated questions. And... (from another

Re: This formating is really tricky

Mark Lawrence wrote: from __past__ import print_statement (untested) I don't think the PEP for the __past__ module has been accepted yet, so you'd have to precede that with from __future__ import __past__ -- Greg -- https://mail.python.org/mailman/listinfo/python-list

Re: This formating is really tricky

ot;.format(f1) pform = " Powerball: {0}".format(f1) for x in range(0, sets): balls = sorted(random.randint(1, 53) for i in range(5)) if balls[0]!= balls[1] and balls[1]!= balls[2] and balls[2]!= balls[3] and balls[3]!= balls[4]: print(bform.format(*balls), pform.form

Re: This formating is really tricky

On Tuesday 26 August 2014 12:13:37 Chris Angelico did opine And Gene did reply: > On Wed, Aug 27, 2014 at 2:09 AM, Mark Lawrence wrote: > > On 26/08/2014 12:24, MRAB wrote: > >> On 2014-08-26 06:57, Mark Lawrence wrote: > >>> On 26/08/2014 02:10, Joel Goldstick wrote: > you should try python

Re: This formating is really tricky

On 26/08/2014 17:33, Chris Angelico wrote: On Wed, Aug 27, 2014 at 2:28 AM, Peter Otten <__pete...@web.de> wrote: No, "python-flight-attendant" ;) http://xkcd.com/353/ Would be nice if that could be made Python 3 compatible. ChrisA Easy. from __past__ import print_statement (untested) -

Re: This formating is really tricky

On Wed, Aug 27, 2014 at 2:28 AM, Peter Otten <__pete...@web.de> wrote: > No, "python-flight-attendant" ;) > > http://xkcd.com/353/ Would be nice if that could be made Python 3 compatible. ChrisA -- https://mail.python.org/mailman/listinfo/python-list

Re: This formating is really tricky

MRAB wrote: > On 2014-08-26 06:57, Mark Lawrence wrote: >> On 26/08/2014 02:10, Joel Goldstick wrote: >>> you should try python-tudor mailing list >>> >> >> I'd try python-stewart and please don't top post, you've been around >> long enough and ought to know better :) >> > Should that be "python-s

Re: This formating is really tricky

On Wed, Aug 27, 2014 at 2:09 AM, Mark Lawrence wrote: > On 26/08/2014 12:24, MRAB wrote: >> >> On 2014-08-26 06:57, Mark Lawrence wrote: >>> >>> On 26/08/2014 02:10, Joel Goldstick wrote: you should try python-tudor mailing list >>> >>> I'd try python-stewart and please don't top po

Re: This formating is really tricky

On 26/08/2014 12:24, MRAB wrote: On 2014-08-26 06:57, Mark Lawrence wrote: On 26/08/2014 02:10, Joel Goldstick wrote: you should try python-tudor mailing list I'd try python-stewart and please don't top post, you've been around long enough and ought to know better :) Should that be "python

Re: This formating is really tricky

>>> you should try python-tudor mailing list >>> >> >> I'd try python-stewart and please don't top post, you've been around >> long enough and ought to know better :) >> > Should that be "python-stuart"? > -- > https://mail.python.org/mailman/listinfo/python-list Glad I could add to the discussion

Re: This formating is really tricky

On 2014-08-26 06:57, Mark Lawrence wrote: On 26/08/2014 02:10, Joel Goldstick wrote: you should try python-tudor mailing list I'd try python-stewart and please don't top post, you've been around long enough and ought to know better :) Should that be "python-stuart"? -- https://mail.python.o

Re: This formating is really tricky

On Tue, 26 Aug 2014 12:32:14 +0300, Marko Rauhamaa wrote: > alister : > >> Oh Wow I didn't know Python was that old - it even pre-dates >> Electricity :-) > > Electricity arose already before the Great Inflation. > > > Marko but it was not in controlled use by mankind at that time -- Whip

Re: This formating is really tricky

alister : > Oh Wow I didn't know Python was that old - it even pre-dates > Electricity :-) Electricity arose already before the Great Inflation. Marko -- https://mail.python.org/mailman/listinfo/python-list

Re: This formating is really tricky

On Mon, 25 Aug 2014 21:10:47 -0400, Joel Goldstick wrote: > you should try python-tudor mailing list > Oh Wow I didn't know Python was that old - it even pre-dates Electricity :-) -- Hand, n.: A singular instrument worn at the end of a human arm and commonly thrust into somebod

Re: This formating is really tricky

On Tue, Aug 26, 2014 at 4:17 PM, Gregory Ewing wrote: > Joel Goldstick wrote: >> >> you should try python-tudor mailing list > > ^ > Hmmm. I wonder what version of Python Henry VIII used? Version 8.0, in a modern numbering scheme. See, those letters after his name are

Re: This formating is really tricky

Joel Goldstick wrote: you should try python-tudor mailing list ^ Hmmm. I wonder what version of Python Henry VIII used? -- Greg -- https://mail.python.org/mailman/listinfo/python-list

Re: This formating is really tricky

On 26/08/2014 02:10, Joel Goldstick wrote: you should try python-tudor mailing list I'd try python-stewart and please don't top post, you've been around long enough and ought to know better :) -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our la

Re: This formating is really tricky

On Mon, 25 Aug 2014 14:05:01 -0700 (PDT), Rustom Mody wrote: >On Tuesday, August 26, 2014 1:44:40 AM UTC+5:30, Seymore4Head wrote: >> BTW the exercise instructions say to use the choice function. I >> assume I had to include all the numbers to choose from instead of >> picking a random number fr

Re: This formating is really tricky

On Mon, 25 Aug 2014 21:52:24 +0100, Mark Lawrence wrote: >On 25/08/2014 21:14, Seymore4Head wrote: >> >> I included my shortcut for pb2. It doesn't work? Is there a short to >> prevent from listing each number? >> > >If it doesn't work then fix it and it will work. Alternatively define >what

Re: This formating is really tricky

On Tue, 26 Aug 2014 12:45:45 +1000, Steven D'Aprano wrote: >Seymore4Head wrote: > >> import random >> sets=3 >> for x in range(0, sets): >> pb1=random.choice([1,2,3,4,5,6,7,8,9,10 [...] 52,53]) >> pb2=random.choice([1-53]) > >You can avoid the annoyance of typing out long lists of sequent

Re: This formating is really tricky

Seymore4Head wrote: > import random > sets=3 > for x in range(0, sets): > pb1=random.choice([1,2,3,4,5,6,7,8,9,10 [...] 52,53]) > pb2=random.choice([1-53]) You can avoid the annoyance of typing out long lists of sequential numbers by using the range() function. And you can avoid writing o

Re: This formating is really tricky

> >>def ran53(): >> return random.randint(1, 53) >> >>f1 = '{:2d}' >>bform = "Your numbers: [{0}, {0}, {0}, {0}, {0}]".format(f1) >>pform = " Powerball: {0}".format(f1) >> >>for x in range(0, sets): >> ball

  1   2   3   4   5   6   7   8   9   10   >