l can't use pip in python 3.11.2

    从 Windows 版[1]邮件发送   References Visible links 1. https://go.microsoft.com/fwlink/?LinkId=550986 -- https://mail.python.org/mailman/listinfo/python-list

Re: Write a function sorting(L).

On 2017-04-21 12:58, Mohammed Ahmed wrote: > Write a function sorting(L) that takes a list of numbers and > returns the list with all elements sorted in ascending order. > Note: do not use the sort built in function > > it is a python question No "sort" fun

Re: Write a function sorting(L).

On 21/04/2017 21:04, Mohammed Ahmed wrote: On Friday, April 21, 2017 at 10:02:55 PM UTC+2, Chris Angelico wrote: On Sat, Apr 22, 2017 at 5:58 AM, Mohammed Ahmed wrote: Write a function sorting(L) that takes a list of numbers and returns the list with all elements sorted in ascending order

Re: Write a function group(L).

On 04/21/2017 01:01 PM, Mohammed Ahmed wrote: Write a function group(L) that takes a list of integers. The function returns a list of two lists one containing the even values and another containing the odd values. it is a python question In fact, this is *not* a question, Python or otherwise

Re: Write a function group(L).

On Fri, Apr 21, 2017 at 2:01 PM, Mohammed Ahmed wrote: > Write a function group(L) that takes a list of integers. The function returns > a list of > two lists one containing the even values and another containing the odd > values. > > it is a python question This group wil

Re: Write a function sorting(L).

On 04/21/2017 01:58 PM, Mohammed Ahmed wrote: > Write a function sorting(L) that takes a list of numbers and returns the list > with all > elements sorted in ascending order. > Note: do not use the sort built in function > > it is a python question Sounds like a basic homewor

Re: Write a function sorting(L).

On 04/21/2017 01:04 PM, Mohammed Ahmed wrote: On Friday, April 21, 2017 at 10:02:55 PM UTC+2, Chris Angelico wrote: On Sat, Apr 22, 2017 at 5:58 AM, Mohammed Ahmed wrote: Write a function sorting(L) that takes a list of numbers and returns the list with all elements sorted in ascending order

Re: Write a function sorting(L).

On Sat, Apr 22, 2017 at 6:04 AM, Mohammed Ahmed wrote: > On Friday, April 21, 2017 at 10:02:55 PM UTC+2, Chris Angelico wrote: >> On Sat, Apr 22, 2017 at 5:58 AM, Mohammed Ahmed >> wrote: >> > Write a function sorting(L) that takes a list of numbers and returns

Re: Write a function sorting(L).

On Friday, April 21, 2017 at 10:02:55 PM UTC+2, Chris Angelico wrote: > On Sat, Apr 22, 2017 at 5:58 AM, Mohammed Ahmed wrote: > > Write a function sorting(L) that takes a list of numbers and returns the > > list with all > > elements sorted in ascending order. > >

Re: Write a function sorting(L).

On Friday, April 21, 2017 at 10:01:40 PM UTC+2, alister wrote: > On Fri, 21 Apr 2017 12:58:52 -0700, Mohammed Ahmed wrote: > > > Write a function sorting(L) that takes a list of numbers and returns the > > list with all elements sorted in ascending order. > > Note: do n

Write a function group(L).

Write a function group(L) that takes a list of integers. The function returns a list of two lists one containing the even values and another containing the odd values. it is a python question -- https://mail.python.org/mailman/listinfo/python-list

Re: Write a function sorting(L).

On Fri, 21 Apr 2017 12:58:52 -0700, Mohammed Ahmed wrote: > Write a function sorting(L) that takes a list of numbers and returns the > list with all elements sorted in ascending order. > Note: do not use the sort built in function > > it is a python question & the reason f

Re: Write a function sorting(L).

On Sat, Apr 22, 2017 at 5:58 AM, Mohammed Ahmed wrote: > Write a function sorting(L) that takes a list of numbers and returns the list > with all > elements sorted in ascending order. > Note: do not use the sort built in function > > it is a python question Yes, it is. It look

Write a function sorting(L).

Write a function sorting(L) that takes a list of numbers and returns the list with all elements sorted in ascending order. Note: do not use the sort built in function it is a python question -- https://mail.python.org/mailman/listinfo/python-list

Re: K&L graph partitioning code offer

gt; > (Is 18 years a record for thread necromancy?) > > I don't see any reply to a post from 1998 here... What post are you > talking about? The Google Groups interface shows that the first post in this thread is as follows: > From: dwh...@ksu.edu (Dean Hall) > Subject: K&

Re: K&L graph partitioning code offer

On 03/29/2017 11:17 AM, jlada...@itu.edu wrote: > On Wednesday, March 29, 2017 at 1:23:48 AM UTC-7, arpitam...@gmail.com wrote: >> Hi >> I am planning to tweak the Kernighan Lin algorithm a bit use coercing of >> certain vertices .I was wondering if u would be kind enough to share the >> python

Re: K&L graph partitioning code offer

On Wednesday, March 29, 2017 at 1:23:48 AM UTC-7, arpitam...@gmail.com wrote: > Hi > I am planning to tweak the Kernighan Lin algorithm a bit use coercing of > certain vertices .I was wondering if u would be kind enough to share the > python code with me so that i can include my idea in it. Goo

Re: K&L graph partitioning code offer

On Wed, 29 Mar 2017 07:29 pm, arpitamishra...@gmail.com wrote: > Hi > I am planning to tweak the Kernighan Lin algorithm a bit use coercing of > certain vertices .I was wondering if u would be kind enough to share the > python code with me so that i can include my idea in it. https://www.google.

K&L graph partitioning code offer

Hi I am planning to tweak the Kernighan Lin algorithm a bit use coercing of certain vertices .I was wondering if u would be kind enough to share the python code with me so that i can include my idea in it. -- https://mail.python.org/mailman/listinfo/python-list

K&L graph partitioning code offer

Hi I am planning to tweak the Kernighan Lin algorithm a bit use coercing of certain vertices .I was wondering if u would be kind enough to share the python code with me so that i can include my idea in it. -- https://mail.python.org/mailman/listinfo/python-list

Re: l = range(int(1E9))

On 03/05/2015 12:30, Chris Angelico wrote: On Sun, May 3, 2015 at 9:16 PM, Steven D'Aprano wrote: On Sun, 3 May 2015 12:16 pm, Mark Lawrence wrote: I doubt that six will ever make the standard library as 2.7 only has another five years in official support. By that time I suppose we'll to goi

Re: l = range(int(1E9))

On Sun, May 3, 2015 at 9:16 PM, Steven D'Aprano wrote: > On Sun, 3 May 2015 12:16 pm, Mark Lawrence wrote: > >> I doubt that six will ever make the standard library as 2.7 only has >> another five years in official support. By that time I suppose we'll to >> going through the porting pain all ove

Re: l = range(int(1E9))

On Sun, May 3, 2015 at 9:15 PM, Steven D'Aprano wrote: > Or if you prefer: > > try: > range = xrange > except NameError: > pass > > and just use range. I prefer this idiom, on the basis that code should be written for the more recent version, and have minimal code to support older version

Re: l = range(int(1E9))

On Sun, 3 May 2015 02:51 pm, Ian Kelly wrote: > On Sat, May 2, 2015 at 5:51 PM, Terry Reedy wrote: >> On 5/2/2015 5:31 PM, Ian Kelly wrote: >> >>> Would it have been better if range() had been implemented as xrange() >>> from the beginning? Sure, that would have been great. Except for one >>> sma

Re: l = range(int(1E9))

On Sun, 3 May 2015 12:16 pm, Mark Lawrence wrote: > I doubt that six will ever make the standard library as 2.7 only has > another five years in official support.  By that time I suppose we'll to > going through the porting pain all over again with the transition from > Python 3 to Python 4.  Alri

Re: l = range(int(1E9))

On Sun, 3 May 2015 08:33 am, BartC wrote: > OK, so it's just an irritation then, as a workaround has been available > for a long time. (For example, if you use xrange, it won't work on 3.x. > If you use range, then it might be inefficient on 2.x.) That is trivially easy to deal with. Put this at

Re: l = range(int(1E9))

On Sun, 3 May 2015 07:40 am, Jon Ribbens wrote: > On 2015-05-02, BartC wrote: >> So do I, I think, if no-one is willing to admit that the original way of >> implementing range() was a glaring mistake. > > I think the issue is that nobody else here thinks the "original way" > of iterating was to

Re: l = range(int(1E9))

On Sun, May 3, 2015 at 8:32 PM, Steven D'Aprano wrote: > scripting > languages often lack a C-style for-loop, using a foreach loop instead. E.g. > I believe the canonical way to loop in bash is something like: > > for $i in `seq start stop` do ... > > (by memory). Newer versions of bash have

Re: l = range(int(1E9))

On Sun, 3 May 2015 07:28 am, Tony the Tiger wrote: > On Fri, 01 May 2015 14:42:04 +1000, Steven D'Aprano wrote: > >> use "l" as a variable name, as it looks too much like 1 > > If you use a better font, they are very different. Besides, a variable > name cann

Re: l = range(int(1E9))

On Sun, 3 May 2015 02:17 am, BartC wrote: > But for looping over a simple integer range, then using 'range' to > denote the range (and build a list as it used to do), was how it was > done. And earlier on people would have been porting coding code to > Python at which point a straightforward 'for

Re: l = range(int(1E9))

On Sat, May 2, 2015 at 5:51 PM, Terry Reedy wrote: > On 5/2/2015 5:31 PM, Ian Kelly wrote: > >> Would it have been better if range() had been implemented as xrange() >> from the beginning? Sure, that would have been great. Except for one >> small detail: the iterator protocol didn't exist back the

Re: l = range(int(1E9))

On 2015-05-03, Terry Reedy wrote: > On 5/2/2015 8:01 PM, Jon Ribbens wrote: >> On 2015-05-02, Terry Reedy wrote: >>> On 5/2/2015 5:40 PM, Jon Ribbens wrote: For information, it looks like xrange() was added on 26 Oct 1993, which pre-dates Python 1.0. >>> >>> 1.0 was released Feb 1991.

Re: l = range(int(1E9))

On 5/2/2015 8:01 PM, Jon Ribbens wrote: On 2015-05-02, Terry Reedy wrote: On 5/2/2015 5:40 PM, Jon Ribbens wrote: For information, it looks like xrange() was added on 26 Oct 1993, which pre-dates Python 1.0. 1.0 was released Feb 1991. 3.2 exactly 20 years later. No, you are thinking of 0.

Re: l = range(int(1E9))

On 03/05/2015 03:07, Michael Torrie wrote: On 05/02/2015 04:33 PM, BartC wrote: OK, so it's just an irritation then, as a workaround has been available for a long time. (For example, if you use xrange, it won't work on 3.x. If you use range, then it might be inefficient on 2.x.) In both Python

Re: l = range(int(1E9))

On 05/02/2015 04:33 PM, BartC wrote: > OK, so it's just an irritation then, as a workaround has been available > for a long time. (For example, if you use xrange, it won't work on 3.x. > If you use range, then it might be inefficient on 2.x.) In both Python 2.7 and 3.3+, you can use the 3rd-part

Re: l = range(int(1E9))

> I don't have much Python code lying around, but the first couple of > files I looked at (not mine), one had this: > >for i in range(7,-1,-1): > for j in range(8): > > another had: > > for l in range(1,17): >for i in range(1, self.bits

Re: l = range(int(1E9))

On 2015-05-02, Terry Reedy wrote: > On 5/2/2015 5:40 PM, Jon Ribbens wrote: >> For information, it looks like xrange() was added on 26 Oct 1993, >> which pre-dates Python 1.0. > > 1.0 was released Feb 1991. 3.2 exactly 20 years later. No, you are thinking of 0.9, which was indeed February 1991.

Re: l = range(int(1E9))

On 5/2/2015 5:31 PM, Ian Kelly wrote: Would it have been better if range() had been implemented as xrange() from the beginning? Sure, that would have been great. Except for one small detail: the iterator protocol didn't exist back then. For loops originally used the getitem iterator protocol.

Re: l = range(int(1E9))

On 5/2/2015 5:40 PM, Jon Ribbens wrote: For information, it looks like xrange() was added on 26 Oct 1993, which pre-dates Python 1.0. 1.0 was released Feb 1991. 3.2 exactly 20 years later. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list

Re: l = range(int(1E9))

On 5/2/2015 11:26 AM, BartC wrote: When I first looked at Python 20 or so years ago this seemed to be the standard way of writing a for-loop: for i in range(N): As Mark said, the actual syntax was originally for item in sequence: ... where sequence technically meant an object with

Re: l = range(int(1E9))

nge(), for anything other than extremely small ranges. What /is/ the way to iterate then? I don't have much Python code lying around, but the first couple of files I looked at (not mine), one had this: for i in range(7,-1,-1): for j in range(8): another had: for l in range(1,1

Re: l = range(int(1E9))

On 02/05/2015 22:40, Jon Ribbens wrote: On 2015-05-02, BartC wrote: So do I, I think, if no-one is willing to admit that the original way of implementing range() was a glaring mistake. I think the issue is that nobody else here thinks the "original way" of iterating was to use range(), for an

Re: l = range(int(1E9))

On 2015-05-02, BartC wrote: > So do I, I think, if no-one is willing to admit that the original way of > implementing range() was a glaring mistake. I think the issue is that nobody else here thinks the "original way" of iterating was to use range(), for anything other than extremely small range

Re: l = range(int(1E9))

On Sat, May 2, 2015 at 3:28 PM, Tony the Tiger wrote: > On Fri, 01 May 2015 14:42:04 +1000, Steven D'Aprano wrote: > >> use "l" as a variable name, as it looks too much like 1 > > If you use a better font, they are very different. Besides, a variable > name c

Re: l = range(int(1E9))

On Sat, May 2, 2015 at 1:51 PM, BartC wrote: > On 02/05/2015 20:15, Mark Lawrence wrote: >> >> On 02/05/2015 19:34, BartC wrote: > > >>> OK, so it's the programmer's fault if as fundamental a concept as a >>> for-loop ranging over integers is implemented inefficiently. He has to >>> transform it i

Re: l = range(int(1E9))

>> I give up. > > > So do I, I think, if no-one is willing to admit that the original way of > implementing range() was a glaring mistake. > > > -- > Bartc > It doesn't matter for small ranges. Anyway it was fixed. > > > -- > https://mail.python.org/mailman/listinfo/python-list -- Joel Goldsti

Re: l = range(int(1E9))

On 02/05/2015 20:15, Mark Lawrence wrote: On 02/05/2015 19:34, BartC wrote: OK, so it's the programmer's fault if as fundamental a concept as a for-loop ranging over integers is implemented inefficiently. He has to transform it into high-level terms, or has to reconstruct it somehow using a wh

Re: l = range(int(1E9))

Mark Lawrence : > On 02/05/2015 19:34, BartC wrote: >> [...] >> [...] >> [...] >> [...] >> [...] >> [...] >> [...] >> [...] >> [...] >> [...] >> [...] >> [...] >> [...] >> [...] [etc etc etc] > > I give up. Mark, you do a commendable job admonishing the forum participants against top-posting. Let

Re: l = range(int(1E9))

BartC : > (I tried an empty loop counting to 1 billion in Python 2.x, using 'for > i in range'. It ran out of memory. Counting to 100 million instead, it > worked, but still used a massive 1.5GB RAM while doing so (and took 6 > seconds to count to 100M, not too bad for Python) > > Outside Python,

Re: l = range(int(1E9))

On 02/05/2015 19:34, BartC wrote: On 02/05/2015 17:39, Mark Lawrence wrote: On 02/05/2015 17:17, BartC wrote: On 02/05/2015 16:40, Mark Lawrence wrote: for item in items: When did this change, or has it always been this way and you were simply using an idiom from other languages? Your ex

Re: l = range(int(1E9))

On 02/05/2015 17:39, Mark Lawrence wrote: On 02/05/2015 17:17, BartC wrote: On 02/05/2015 16:40, Mark Lawrence wrote: for item in items: When did this change, or has it always been this way and you were simply using an idiom from other languages? Your example is the equivalent of 'forall'

Re: l = range(int(1E9))

On 02/05/2015 17:17, BartC wrote: On 02/05/2015 16:40, Mark Lawrence wrote: On 02/05/2015 16:26, BartC wrote: On 30/04/2015 18:20, Ben Finney wrote: Jon Ribbens writes: If you use xrange() instead of range() then you will get an iterator which will return each of the numbers in turn withou

Re: l = range(int(1E9))

On 02/05/2015 16:40, Mark Lawrence wrote: On 02/05/2015 16:26, BartC wrote: On 30/04/2015 18:20, Ben Finney wrote: Jon Ribbens writes: If you use xrange() instead of range() then you will get an iterator which will return each of the numbers in turn without any need to create an enormous li

Re: l = range(int(1E9))

On 02/05/2015 16:26, BartC wrote: On 30/04/2015 18:20, Ben Finney wrote: Jon Ribbens writes: If you use xrange() instead of range() then you will get an iterator which will return each of the numbers in turn without any need to create an enormous list of all of them. If you use Python 3 in

Re: l = range(int(1E9))

On 30/04/2015 18:20, Ben Finney wrote: Jon Ribbens writes: If you use xrange() instead of range() then you will get an iterator which will return each of the numbers in turn without any need to create an enormous list of all of them. If you use Python 3 instead of the obsolescent Python 2,

Re: l = range(int(1E9))

On 5/1/2015 1:04 AM, Cecil Westerhof wrote: By the way: I also see python3.4 and python3.4m. Any idea where the m stands for? I never heard of that in 18 years of Python, and thought it must be an error, but putting 'python3.4b' into google search return this. https://stackoverflow.com/ques

Re: l = range(int(1E9))

Op Friday 1 May 2015 15:25 CEST schreef Michael Torrie: > On 04/30/2015 10:19 PM, Cecil Westerhof wrote: >>> I must also confess to being highly impressed, it's a breath of >>> fresh air having an apprentice Pythonista who is looking at doing >>> things the Pythonic way :) >> >> When in Rome, do a

Re: l = range(int(1E9))

On 04/30/2015 10:19 PM, Cecil Westerhof wrote: >> I must also confess to being highly impressed, it's a breath of >> fresh air having an apprentice Pythonista who is looking at doing >> things the Pythonic way :) > > When in Rome, do as the Romans do. > > Besides: there probably is a reason for t

Re: l = range(int(1E9))

Op Friday 1 May 2015 13:15 CEST schreef Thomas Lahn: > Cecil Westerhof wrote: > >> By the way: I also see python3.4 and python3.4m. Any idea where the >> m stands for? > > I googled for “python3.4m” and found as second result Eh, I could/should have done that myself. :-( Nice that you do not burn

Re: l = range(int(1E9))

Cecil Westerhof wrote: > By the way: I also see python3.4 and python3.4m. Any idea where the m > stands for? I googled for “python3.4m” and found as second result In a nutshell: python3.4m was buil

Re: l = range(int(1E9))

Op Friday 1 May 2015 07:20 CEST schreef Steven D'Aprano: > Some programming language virtual machines limit how much memory > they will use. The CPython VM isn't one of those, although I > understand that both Jython and IronPython are. (I may be wrong -- Jython runs in the JVM, so Jython is. --

Re: l = range(int(1E9))

s/129587/does-ulimit-m-not-work-on-modern-linux > > Based on some quick testing[1], it doesn't appear to work on OpenBSD > or FreeBSD either. Yes, as I already found out you need to use -v. But it would be nice that there was an indication that -m is obsolete. Depending on the available m

Re: l = range(int(1E9))

On Fri, 1 May 2015 03:20 am, Ben Finney wrote: > Jon Ribbens writes: > >> On 2015-04-30, Cecil Westerhof wrote: >> > If I execute: >> > l = range(int(1E9) >> > >> > The python process gobbles up all the memory and is killed. […] Is >> >

Re: l = range(int(1E9))

Op Friday 1 May 2015 01:12 CEST schreef Ben Finney: > Chris Angelico writes: > >> Very easily and simply: Python 3 and Python 2 will always install >> separately, and the only possible conflicts are over the "python" >> command in PATH and which program is associated with ".py" files. > > Calling

Re: l = range(int(1E9))

Op Friday 1 May 2015 06:42 CEST schreef Steven D'Aprano: > On Fri, 1 May 2015 02:06 am, Cecil Westerhof wrote: > >> If I execute: >> l = range(int(1E9) > > > Others have already answered your questions about memory. Let me > answer the question you didn'

Re: l = range(int(1E9))

On Fri, 1 May 2015 02:06 am, Cecil Westerhof wrote: > If I execute: > l = range(int(1E9) Others have already answered your questions about memory. Let me answer the question you didn't ask about style :-) Don't use "l" as a variable name, as it looks too much l

Re: l = range(int(1E9))

On 01/05/2015 05:19, Cecil Westerhof wrote: Op Thursday 30 Apr 2015 22:53 CEST schreef Mark Lawrence: On 30/04/2015 19:50, Cecil Westerhof wrote: Op Thursday 30 Apr 2015 19:12 CEST schreef Rob Gaddi: This also leads to a unrelated question, Cecil. Given that you really are just starting to g

Re: l = range(int(1E9))

Op Thursday 30 Apr 2015 22:53 CEST schreef Mark Lawrence: > On 30/04/2015 19:50, Cecil Westerhof wrote: >> Op Thursday 30 Apr 2015 19:12 CEST schreef Rob Gaddi: >> >>> This also leads to a unrelated question, Cecil. Given that you >>> really are just starting to get your Python feet under you, why

Re: Use 'python2' or 'python3', explicit is better than implicit (was: l = range(int(1E9)))

On Friday, May 1, 2015 at 4:50:45 AM UTC+5:30, Ben Finney wrote: > Chris Angelico writes: > > > Very easily and simply: Python 3 and Python 2 will always install > > separately, and the only possible conflicts are over the "python" > > command in PATH and which program is associated with ".py" fi

Re: l = range(int(1E9))

On Fri, May 1, 2015 at 9:12 AM, Ben Finney wrote: > Chris Angelico writes: > >> Very easily and simply: Python 3 and Python 2 will always install >> separately, and the only possible conflicts are over the "python" >> command in PATH and which program is associated with ".py" files. > > Calling ‘

Use ‘python2’ or ‘python3’, explicit is better than implicit (was: l = range(int(1E9)))

Chris Angelico writes: > Very easily and simply: Python 3 and Python 2 will always install > separately, and the only possible conflicts are over the "python" > command in PATH and which program is associated with ".py" files. Using the ‘python’ command is now ambiguous, and with Python 2 slippi

Re: l = range(int(1E9))

Chris Angelico writes: > Very easily and simply: Python 3 and Python 2 will always install > separately, and the only possible conflicts are over the "python" > command in PATH and which program is associated with ".py" files. Calling ‘python’ is now ambiguous, and with Python 2 slipping inexora

Re: l = range(int(1E9))

Chris Angelico wrote: > Very easily and simply: Python 3 and Python 2 will always install separately, and the only possible conflicts are over the "python" command in PATH and which program is associated with ".py" files. You can fix both of them by installing a recent version of Python and usin

Re: l = range(int(1E9))

On Fri, May 1, 2015 at 7:23 AM, ElChino wrote: > Mark Lawrence wrote: > >> You might find this useful then in you haven't already seen it >> https://docs.python.org/3/howto/pyporting.html > > > The main reason I haven't switched to Python3 (from 2.7.4/MSVC), > is fear of a major breakage. How can

Re: l = range(int(1E9))

On 2015-04-30 22:18, Cecil Westerhof wrote: > Op Thursday 30 Apr 2015 20:59 CEST schreef Dave Angel: >> ulimit is your friend if you've got a program that wants to gobble >> up all of swap space. > > Yes, my system is openSUSE 64 bit. I really should look into ulimit. > The default is: [snip] >

Re: l = range(int(1E9))

Mark Lawrence wrote: You might find this useful then in you haven't already seen it https://docs.python.org/3/howto/pyporting.html The main reason I haven't switched to Python3 (from 2.7.4/MSVC), is fear of a major breakage. How can I be certain that even if I install to different directories,

Re: l = range(int(1E9))

On 30/04/2015 19:50, Cecil Westerhof wrote: Op Thursday 30 Apr 2015 19:12 CEST schreef Rob Gaddi: This also leads to a unrelated question, Cecil. Given that you really are just starting to get your Python feet under you, why are you using Python2? Python3 is the standard now, Python2 is really

Re: l = range(int(1E9))

Op Thursday 30 Apr 2015 20:59 CEST schreef Dave Angel: > On 04/30/2015 02:48 PM, alister wrote: >> On Thu, 30 Apr 2015 20:23:31 +0200, Gisle Vanem wrote: >> >>> Cecil Westerhof wrote: >>> >>>> If I execute: >>>> l = range(int(1E9) >

Re: l = range(int(1E9))

Grant Edwards schreef op 2015-04-30 18:33: On 2015-04-30, Cecil Westerhof wrote: If I execute: l = range(int(1E9) The python process gobbles up all the memory and is killed. The problem is that after this my swap is completely used, because other processes have swapped to it. This make

Re: l = range(int(1E9))

Op Thursday 30 Apr 2015 19:41 CEST schreef Ben Finney: > Cecil Westerhof writes: > >> That works, yes. Now I get a MemoryError and the other processes >> are left alone. Now determining what are the best values. > > I would strongly recommend that “best values” includes “run Python > version >= 3

Re: l = range(int(1E9))

Op Thursday 30 Apr 2015 19:12 CEST schreef Rob Gaddi: > This also leads to a unrelated question, Cecil. Given that you > really are just starting to get your Python feet under you, why are > you using Python2? Python3 is the standard now, Python2 is really > just given legacy support. I'd understa

Re: l = range(int(1E9))

On 04/30/2015 02:48 PM, alister wrote: On Thu, 30 Apr 2015 20:23:31 +0200, Gisle Vanem wrote: Cecil Westerhof wrote: If I execute: l = range(int(1E9) The python process gobbles up all the memory and is killed. The problem is that after this my swap is completely used, because other

Re: l = range(int(1E9))

On Thu, 30 Apr 2015 20:23:31 +0200, Gisle Vanem wrote: > Cecil Westerhof wrote: > >> If I execute: >> l = range(int(1E9) >> >> The python process gobbles up all the memory and is killed. The problem >> is that after this my swap is completely used, becaus

Re: l = range(int(1E9))

Cecil Westerhof wrote: If I execute: l = range(int(1E9) The python process gobbles up all the memory and is killed. The problem is that after this my swap is completely used, because other processes have swapped to it. This make those programs more slowly. Is there a way to circumvent

Re: l = range(int(1E9))

Op Thursday 30 Apr 2015 18:55 CEST schreef Jon Ribbens: > On 2015-04-30, Cecil Westerhof wrote: >> If I execute: >> l = range(int(1E9) >> >> The python process gobbles up all the memory and is killed. The >> problem is that after this my swap is completely used

Re: l = range(int(1E9))

Cecil Westerhof writes: > That works, yes. Now I get a MemoryError and the other processes are > left alone. Now determining what are the best values. I would strongly recommend that “best values” includes “run Python version >= 3”. One of the many problems you avoid by leaving Python 2 behind

Re: l = range(int(1E9))

Op Thursday 30 Apr 2015 18:33 CEST schreef Grant Edwards: > On 2015-04-30, Cecil Westerhof wrote: >> If I execute: >> l = range(int(1E9) >> >> The python process gobbles up all the memory and is killed. The >> problem is that after this my swap is completely used

Re: l = range(int(1E9))

Jon Ribbens writes: > On 2015-04-30, Cecil Westerhof wrote: > > If I execute: > > l = range(int(1E9) > > > > The python process gobbles up all the memory and is killed. […] Is > > there a way to circumvent Python claiming all the memory? You seem to be a

Re: l = range(int(1E9))

On Thu, 30 Apr 2015 10:05:44 -0700, Gary Herron wrote: > On 04/30/2015 09:06 AM, Cecil Westerhof wrote: >> If I execute: >> l = range(int(1E9) >> >> The python process gobbles up all the memory and is killed. The problem >> is that after this my swap

Re: l = range(int(1E9))

On 04/30/2015 09:06 AM, Cecil Westerhof wrote: If I execute: l = range(int(1E9) The python process gobbles up all the memory and is killed. The problem is that after this my swap is completely used, because other processes have swapped to it. This make those programs more slowly. Is there

Re: l = range(int(1E9))

On 4/30/2015 12:06 PM, Cecil Westerhof wrote: If I execute: l = range(int(1E9) you get a SyntaxError The python process gobbles up all the memory and is killed. The problem is that after this my swap is completely used, because other processes have swapped to it. This make those

Re: l = range(int(1E9))

On 2015-04-30, Cecil Westerhof wrote: > If I execute: > l = range(int(1E9) > > The python process gobbles up all the memory and is killed. The > problem is that after this my swap is completely used, because other > processes have swapped to it. This make those progra

Re: l = range(int(1E9))

On 2015-04-30, Cecil Westerhof wrote: > If I execute: > l = range(int(1E9) > > The python process gobbles up all the memory and is killed. The > problem is that after this my swap is completely used, because other > processes have swapped to it. This make those programs

l = range(int(1E9))

If I execute: l = range(int(1E9) The python process gobbles up all the memory and is killed. The problem is that after this my swap is completely used, because other processes have swapped to it. This make those programs more slowly. Is there a way to circumvent Python claiming all the memory

Re: L-system equations drawing tool

On 7/17/2014 5:38 PM, Yaşar Arabacı wrote: Hi, I wrote a small program to draw L-system equations using tkinter. You can find it on https://github.com/yasar11732/tklsystem It is still under development, but seems to be working nice so far. I could only try it on windows, but it should work on

L-system equations drawing tool

Hi, I wrote a small program to draw L-system equations using tkinter. You can find it on https://github.com/yasar11732/tklsystem It is still under development, but seems to be working nice so far. I could only try it on windows, but it should work on Linux too. You will need Python 3.x to run

Re: L[:]

On 1/14/2014 5:42 AM, Albert-Jan Roskam wrote: I also found that item assignment ([1] below) is much faster > than using the more standard (I think) .append ([2]). # [1] for idx,item in enumerate(L[:]): if some_condition: L[idx] = foobarify(item) [1] *is* the standard way

Re: L[:]

On 1/13/2014 4:00 AM, Laszlo Nagy wrote: > >> Unless L is aliased, this is silly code. > There is another use case. If you intend to modify a list within a for > loop that goes over the same list, then you need to iterate over a copy. > And this cannot be called an &quo

Re: L[:]

On 1/13/2014 4:00 AM, Laszlo Nagy wrote: Unless L is aliased, this is silly code. There is another use case. If you intend to modify a list within a for loop that goes over the same list, then you need to iterate over a copy. And this cannot be called an "alias" because it has no n

Re: L[:]

Unless L is aliased, this is silly code. There is another use case. If you intend to modify a list within a for loop that goes over the same list, then you need to iterate over a copy. And this cannot be called an "alias" because it has no name: for idx,item in enumerate(L[:]

  1   2   >