Re: Case Statements

Op 16-03-16 om 20:27 schreef Marko Rauhamaa: > Antoon Pardon : > >> Look at decorators. They don't provide functionality we wouldn't have >> without them. So we don't actually need them. Do you argue that >> introducing them wasn't progress? > I

Re: Case Statements

Op 17-03-16 om 01:31 schreef Chris Angelico: > On Thu, Mar 17, 2016 at 11:19 AM, Steven D'Aprano wrote: >> On Thu, 17 Mar 2016 10:14 am, Chris Angelico wrote: >> >>> On Thu, Mar 17, 2016 at 5:31 AM, Antoon Pardon >>> wrote: >>>> It can be yes. Lo

Re: Case Statements

Op 16-03-16 om 15:02 schreef Mark Lawrence: > On 16/03/2016 13:38, Antoon Pardon wrote: >> Op 16-03-16 om 12:07 schreef Mark Lawrence: >>> >>> Raise the item on the python-ideas mailing list for the umpteenth time >>> then, and see how far you get. >> >

Re: Case Statements

Op 17-03-16 om 03:02 schreef Chris Angelico: > On Thu, Mar 17, 2016 at 12:54 PM, Steven D'Aprano wrote: > >> I wouldn't want to rely on it working with decorator syntax either. Even if >> it does now, I'm not sure that's a language guarantee. > That's the thing, though. It's not a guarantee, yet i

Re: Case Statements

Op 16-03-16 om 18:24 schreef Mark Lawrence: > On 16/03/2016 15:27, Antoon Pardon wrote: >> Op 16-03-16 om 15:02 schreef Mark Lawrence: >>> On 16/03/2016 13:38, Antoon Pardon wrote: >>>> Op 16-03-16 om 12:07 schreef Mark Lawrence: >>>>> >>>>

Re: Case Statements

Op 16-03-16 om 12:07 schreef Mark Lawrence: > On 16/03/2016 10:52, Antoon Pardon wrote: >> Op 16-03-16 om 10:51 schreef Mark Lawrence: >>> On 16/03/2016 09:35, Antoon Pardon wrote: >>>> Op 16-03-16 om 09:47 schreef Mark Lawrence: >>>>> >>>>

Re: Why lambda in loop requires default?

So the i in each run of the block is a new instantiation of the variable instead of being the same variable. -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list

Dictionaries with variable default.

in TypeError: () takes exactly 1 argument (0 given) -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list

Re: Dictionaries with variable default.

Op 03-11-14 om 12:09 schreef Chris Angelico: > On Mon, Nov 3, 2014 at 10:04 PM, Antoon Pardon > wrote: >> Is it possible to have a default dictionary where the default is dependant >> on the key? >> >> I was hoping something like this might work: >>>>>

Is there a cairo like surface for the screen without the window hassle

really interested in. So does someone know of a package that provides a cairo like surface but that would take care of the events in a rather straight forward matter, so that my program could make it's design in a window on the screen just as if it is designing it in a pdf file. -- Antoon P

Re: Is there a cairo like surface for the screen without the window hassle

Op 03-02-15 om 13:17 schreef Nobody: > On Mon, 02 Feb 2015 14:20:56 +0100, Antoon Pardon wrote: > >> I need to have a program construct a number of designs. Of course I can >> directly use a pfd surface and later use a pdf viewer to check. But that >> becomes rather cumbers

Re: Functional programming

ng, *unproductive* part of languages > like Java, C and Pascal. Almost always, you're telling the compiler stuff > that it can work out for itself. In the same way writing unit tests is the most tedious, boring, annoying, *unproductive* part. Amost always you are giving the pro

Re: why indentation should be part of the syntax

o is indented in a place where it is obvious it doesn't match the program structure. -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list

Re: Functional programming

Op 04-03-14 12:47, Steven D'Aprano schreef: > On Tue, 04 Mar 2014 11:56:07 +0100, Antoon Pardon wrote: > >> Op 04-03-14 09:56, Steven D'Aprano schreef: >>>> If you >>>> explicitly say that this is an int, then yes, that should be >>>>

Re: Functional programming

2 is an int? Who would have guessed! How about: decimal[precision=4] x = 2.6; int[min = -10, max = 20] n = 7; -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list

Re: Reference

7;s actually fairly > rare. Usually you'd just accept that True, 1, "yes", [1,2,3], and > 1.2345 are all equally true. No I usually don't accept that. A number different from 0 is not the same as a none-empty list. I usally don't want to treat them the same. -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list

Re: Balanced trees

the wrong one. You are only illustrating one part. How about all those cases now where the wrong choice is more or less forced on the developer for lack of the alternative? -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list

Re: Tuples and immutability

Op 12-03-14 07:28, Steven D'Aprano schreef: > On Tue, 11 Mar 2014 23:25:19 -0400, Terry Reedy wrote: > >> Nope, 'similar' is not 'equivalent'. Evaluating x twice instead of once >> and possibly allocating a new object versus not take extra time. In a >> statement like "x.y.z[3*n+m] += 1", calculati

Re: Tuples and immutability

Op 12-03-14 10:51, Ian Kelly schreef: > On Wed, Mar 12, 2014 at 3:39 AM, Antoon Pardon > wrote: >> The documentation is wrong at that point as the following code illustrates. > Either way it still has to do a getitem and a setitem, but if you have > a more nested structure then

Re: Time we switched to unicode? (was Explanation of this Python language feature?)

but the result is more readable because we are able to use symbols that are already familiar from other contexts, I would say it is worth it. -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list

Re: Time we switched to unicode? (was Explanation of this Python language feature?)

al use braces. That doesn't seem to be a problem in python3. The only question was what should {} represent and how do we get an empty collection of the other kind. If {} had been an empty set, dict() could have been used for an empty dictionary is {:} had been unacceptable. -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list

Re: Time we switched to unicode? (was Explanation of this Python language feature?)

On 25-03-14 10:54, Chris Angelico wrote: > On Tue, Mar 25, 2014 at 8:43 PM, Antoon Pardon > wrote: >> I thought programs were read more than written. So if writing is made >> a bit more problematic but the result is more readable because we are >> able to use symbols t

Re: Time we switched to unicode? (was Explanation of this Python language feature?)

On 25-03-14 12:14, Steven D'Aprano wrote: > On Tue, 25 Mar 2014 11:38:38 +0100, Antoon Pardon wrote: > >> On 25-03-14 10:54, Chris Angelico wrote: >>> On Tue, Mar 25, 2014 at 8:43 PM, Antoon Pardon >>> wrote: >>>> I thought programs were read more

Re: Time we switched to unicode? (was Explanation of this Python language feature?)

On 25-03-14 12:12, Chris Angelico wrote: > On Tue, Mar 25, 2014 at 9:24 PM, Antoon Pardon > wrote: >> No they didn't have to. With the transition to python3, the developers >> could have opted for empty braces to mean an empty set. And if they >> wanted a literal

Re: Time we switched to unicode? (was Explanation of this Python language feature?)

lean. Nor would it be unclean, when you have to write somethings a bit differently when you want your program to be compatible both with python2 and python3. You will also need to prefix all your (unicode) strings with u and all your byte strings with b. And probably some more stuff if you want to a

Re: Time we switched to unicode? (was Explanation of this Python language feature?)

On 25-03-14 13:53, Rustom Mody wrote: > On Tuesday, March 25, 2014 4:08:38 PM UTC+5:30, Antoon Pardon wrote: >> So? We do use + -, so why shouldn't we use × for multiplication. Would >> such a use already indicate I should use a mathematical front-end? >> When a program

Re: Time we switched to unicode? (was Explanation of this Python language feature?)

On 25-03-14 14:36, Steven D'Aprano wrote: > On Tue, 25 Mar 2014 08:21:19 -0400, Roy Smith wrote: > >> In article , >> Antoon Pardon wrote: >> >>> Come on. The problem isn't that both set and dictionary literal use >>> braces. That doesn&

Re: unicode as valid naming symbols

be allowed as an >> identifier. > > No, it shouldn't. Doing so would mean we could not use √ as the > square root operator in the future. And what advantage would that bring over just using it as a function? -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list

Re: unicode as valid naming symbols

equivallent of the following I have never seen. t = 2.5 x = 8.2 y = t √ x Of course we don't have to follow mathematical convention with python. However allowing any unicode symbol as an identifier doesn't prohibit from using √ as an operator. We do have "in" and "

Re: Time we switched to unicode? (was Explanation of this Python language feature?)

as in favor of the switch. In my estimation the cost would have been bearable. But I understand this kind of things is always a judgement call and different people can legitimately come to different conclusions. -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list

Re: FIXED: Dynamically reference variables in object

ss you have specific reasons to use atrributes (what you seem to call variables here), it seems you are better of using a dictionary. So you could then use: device["attr1"]. -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list

Re: YADTR (Yet Another DateTime Rant)

imagine that those who wrote the module and I expect used it often found it a useful representation. -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list

Re: unicode as valid naming symbols

On 26-03-14 17:37, Ian Kelly wrote: > On Wed, Mar 26, 2014 at 2:52 AM, Antoon Pardon > wrote: >> Of course we don't have to follow mathematical convention with python. >> However allowing any >> unicode symbol as an identifier doesn't prohibit from using √ as

Re: YADTR (Yet Another DateTime Rant)

here I was working with a structure that consisted of a whole part and a fracture part where I found it useful to have the fracture part always positive and displayed as such. Your background is obviously different and you don't like it. Fine, that doesn't make it brain dead. -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list

Re: unicode as valid naming symbols

That you are not interested in having to maintain someone's code who would use such symbols is irrelevant. IIRC people have used the exact same kind of argument against decorators and the if-else operator. It seems we are all consenting adults until someone doesn't like the idea how it might influence his job. In that case it shouldn't be allowed. -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list

Re: unicode as valid naming symbols

Op 31-03-14 19:40, Ian Kelly schreef: > On Mon, Mar 31, 2014 at 3:55 AM, Antoon Pardon > wrote: >> On 27-03-14 17:22, Ian Kelly wrote: >>> On Thu, Mar 27, 2014 at 9:28 AM, Mark H Harris >>> wrote: >>>>> Do you think that the ability to write thi

Re: unicode as valid naming symbols

On 01-04-14 02:47, Ian Kelly wrote: > On Mon, Mar 31, 2014 at 1:31 PM, Antoon Pardon > wrote: >> Op 31-03-14 19:40, Ian Kelly schreef: >>> That was an exaggeration on my part. It wouldn't affect my job, as I >>> wouldn't expect to ever actually have to m

Re: unicode as valid naming symbols

On 01-04-14 11:18, Ian Kelly wrote: > On Tue, Apr 1, 2014 at 2:19 AM, Antoon Pardon > wrote: >> On 01-04-14 02:47, Ian Kelly wrote: >> >>> Well, this is the path taken by APL. It has its supporters. It's not >>> known for being readable. >&g

Re: unicode as valid naming symbols

I confess that is mostly personal taste, since I find names_like_this ugly. Names-like-this look better to me but that wouldn't be workable in python. But maybe there is some connector that would be aestetically pleasing and not causing other problems. -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)

ory that would imply we are now speaking of an other language. -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list

Re: [OFF-TOPIC] How do I find a mentor when no one I work with knows what they are doing?

t; a few other questions only tangentially related to the above > I would agree with 1 & 4, but 2 & 3 only happen if you are really lucky > :-) No wonder, because when they do happen, chances are someone will complain about that person not answering the question actually asked. -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list

Strange syntax error, occurs only when script is executed directly

no idea what is going on here. The persmision for /usr/local/bin/ldapwatch look fine: # ls -l /usr/local/bin/ldapwatch -rwxr-xr-x 1 root root 2092 Apr 22 10:05 /usr/local/bin/ldapwatch Does anyone have an idea where I should look to fix this? -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list

Re: Strange syntax error, occurs only when script is executed directly

On 22-04-14 12:42, Frank Millman wrote: > "Antoon Pardon" wrote in message > news:535644a4.6060...@rece.vub.ac.be... >> I am workin on a solaris 11 machine. The python version is 2.7.6 >> path to python is /opt/local/bin/python. >> > [...] >> Now if I e

Re: Strange syntax error, occurs only when script is executed directly [solved]

On 22-04-14 14:09, Chris Angelico wrote: > On Tue, Apr 22, 2014 at 8:29 PM, Antoon Pardon > wrote: >> However if I call the script directly and want the #! line do its work I get >> the following error. >> >> # /usr/local/bin/ldapwatch /opt/local/log/openlda

Re: Strange syntax error, occurs only when script is executed directly [solved]

On 22-04-14 14:26, Chris Angelico wrote: > On Tue, Apr 22, 2014 at 10:21 PM, Antoon Pardon > wrote: >> Yes that was it. I changed the first line of my script to: >> >> #!/opt/local/bin/python2.7 >> >> and it now works. > Excellent! Shebangs are *extremely*

Re: Add "Received:" header to email msg in correct position?

thought that was the job of the SMTP servers, not of email applications. So I'm not sure that what you want to do is the polite thing to do. -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list

Re: Add "Received:" header to email msg in correct position?

On 07-05-14 10:11, Emre Hasegeli wrote: > Antoon Pardon <mailto:antoon.par...@rece.vub.ac.be>>: > > > I'm working on a Python app that receives an e-mail message via > SMTP, > > does some trivial processing on it, and forwards it to another SMTP

Re: python-daemon interaction with multiprocessing (secure-smtpd)

hen belong to its proces group. You can then normally kill all process with pkill -g ... -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list

Re: Add "Received:" header to email msg in correct position?

On 07-05-14 16:32, Grant Edwards wrote: >> So I'm not sure that what you want to do is the polite thing to do. > Why not? Nevermind, I originally hadn't thought things completly through. -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list

python3; ftplib: TypeError: Can't convert 'bytes' object to str implicitly

the locales that other people use. So I manipulate all file and directory names as bytes. Am I doing something wrong? -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list

Re: python3; ftplib: TypeError: Can't convert 'bytes' object to str implicitly

op 14-05-14 18:24, Akira Li schreef: > Antoon Pardon writes: > >> This is the code I run (python 3.3) >> >> host = ... >> user = ... >> passwd = ... >> >> from ftplib import FTP >> >> ftp = FTP(host, user, passwd) >> ft

Re: email 8bit encoding

Op 01-08-13 17:20, ru...@yahoo.com schreef: > On 07/29/2013 02:52 PM, Antoon Pardon wrote: >> Op 29-07-13 01:41, ru...@yahoo.com schreef: >>> How, using Python-3.3's email module, do I "flatten" (I think >>> that's the right term) a Message object

Re: email 8bit encoding

Op 01-08-13 17:20, ru...@yahoo.com schreef: > On 07/29/2013 02:52 PM, Antoon Pardon wrote: >> Op 29-07-13 01:41, ru...@yahoo.com schreef: >>> How, using Python-3.3's email module, do I "flatten" (I think >>> that's the right term) a Message object

Re: Newbie: static typing?

t compile time if you have static typing than if you have to design a test for them, I don't see why that can't be an argument. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list

Re: Using sudo to write to a file as root from a script

xt > on its standard input, and don't bother with the pipe at all. That is probably beside the point. I suspect Adam is just giving a minimal example to show the kind of thing he is trying to do. Nit picking the specific example instead of advising on the problem is likely to be less th

Re: Using sudo to write to a file as root from a script

d mean that the equivallent shell command you are trying to execute is: echo -n stable '|' sudo tee /opt/ldg/etc/channel.conf instead of echo -n stable | sudo tee /opt/ldg/etc/channel.conf which you probably want. You should also take care with the echo command. Echo is usu

Re: Importing variables non-deterministic?

deep down inside some function you might never suspect, is > changing the global variable. I think you are overstating your case. Classes and functions are variables too and in general nobody seems to have a problem with them being global. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list

Re: Importing variables non-deterministic?

Op 19-08-13 09:45, Dave Angel schreef: > Antoon Pardon wrote: > >> Op 17-08-13 17:01, Steven D'Aprano schreef: >>> >>> And here you re-import the name "y" from struct_global. That rebinds the >>> current module's "y" with what

Re: Importing variables non-deterministic?

Op 19-08-13 10:32, Chris Angelico schreef: > On Mon, Aug 19, 2013 at 9:16 AM, Antoon Pardon > wrote: >> Op 19-08-13 09:45, Dave Angel schreef: >>> Antoon Pardon wrote: >>>> I think you are overstating your case. Classes and functions are >>>> variab

Re: Importing variables non-deterministic?

Op 19-08-13 11:18, Chris Angelico schreef: > On Mon, Aug 19, 2013 at 10:03 AM, Antoon Pardon > wrote: >> This is irrelevant. That some context defines a constant, and that you >> can use a variable with the same name as a constant in python, doesn't >> contradict th

Re: Importing variables non-deterministic?

Op 19-08-13 14:33, Dave Angel schreef: > Antoon Pardon wrote: > >> Op 19-08-13 11:18, Chris Angelico schreef: > >>> The issue >>> was regarding imports, and it's perfectly safe to import a constant, >>> even if the interpreter doesn'

Re: Importing variables non-deterministic?

Op 19-08-13 17:04, Chris Angelico schreef: On Mon, Aug 19, 2013 at 3:55 PM, Antoon Pardon wrote: Pity enough they chose a way that didn't allow programmers to protect names they thought important enough to do so too. As of Python 3, we can redefine something that used to be a keyword,

Re: Importing variables non-deterministic?

Op 19-08-13 18:57, Steven D'Aprano schreef: On Mon, 19 Aug 2013 10:16:36 +0200, Antoon Pardon wrote: Op 19-08-13 09:45, Dave Angel schreef: Antoon Pardon wrote: Op 17-08-13 17:01, Steven D'Aprano schreef: And here you re-import the name "y" from struct_global. That

Re: Importing variables non-deterministic?

riends be dependant on math.pi? AfAIR the numerical algorithms for calulating sin and friends don't depend on (the value of) pi. So there is no reason to suspect that altering math.pi would have any effect on the results of these functions. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list

Re: Importing variables non-deterministic?

Op 20-08-13 07:48, Steven D'Aprano schreef: > On Mon, 19 Aug 2013 22:34:00 +0200, Antoon Pardon wrote: > >> Op 19-08-13 19:05, Steven D'Aprano schreef: >> >> >>> I wish Python had stronger support for enforcing constantness, to whit, >>> some w

Re: Importing variables non-deterministic?

Op 20-08-13 09:31, wxjmfa...@gmail.com schreef: > Le mardi 20 août 2013 08:55:18 UTC+2, Antoon Pardon a écrit : >> >>> >> > >> >> >> >>> If you consider the implementation of sin and cos functions, they usually >> >>> redu

Re: Running a command line program and reading the result as it runs

IO with a terminal and so the IO will be line buffered. But all IO from pip will be available through the master in your program. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list

Re: Running a command line program and reading the result as it runs

Op 23-08-13 11:53, Antoon Pardon schreef: > Op 22-08-13 07:51, Ian Simcock schreef: >> Greetings all. >> >> I'm using Python 2.7 under Windows and am trying to run a command line >> program and process the programs output as it is running. A number of >>

Re: New VPS Provider needed

Op 27-08-13 12:00, Νικόλαος schreef: > Στις 27/8/2013 12:38 μμ, ο/η Chris Angelico έγραψε: >> On Tue, Aug 27, 2013 at 7:32 PM, wrote: >>> 27/8/2013 12:06 ��, �/� Tim Delaney ��: On 27 August 2013 18:45, >>> > wrote:

Re: New VPS Provider needed

and get answers about cats. > You dont like my questions, block me, but just stop answering unhelpfully. You are not in a position to demand anything from people here. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list

Re: New VPS Provider needed

I also think you are over reacting. One thread where people come with snide remarks doesn't turn the whole newsgroup/mailinglist into an unpleasant environment. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list

Re: New VPS Provider needed

Op 28-08-13 13:25, Steven D'Aprano schreef: > On Wed, 28 Aug 2013 09:19:40 +0200, Antoon Pardon wrote: > >> Op 27-08-13 18:18, Steven D'Aprano schreef: >>> On Wed, 28 Aug 2013 00:41:17 +1000, Chris Angelico wrote: >>> >>>> On Wed, Aug 28, 2013 a

Re: semicolon at end of python's statements

fined the function into an incomple one. Should some kind of end marker be needed, the problem would have been found much easier, because if would have produced a syntax error. > Looked at that way, other languages seem foolish and burdensome and > Python's indentation is the only sensible way. I don't agree. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list

Re: semicolon at end of python's statements

reasons to move away from map/filter to list comprehension. As I understand it, python made a move away from map and filter towards list comprehension. Chris seems to want some of the possibilities that came with that incorporated into the for statement. And your suggestion is to go back to the old

Re: semicolon at end of python's statements

Op 30-08-13 09:25, Chris Angelico schreef: > On Fri, Aug 30, 2013 at 5:15 PM, Antoon Pardon > wrote: >> Op 30-08-13 06:55, Ben Finney schreef: >>> Ben Finney writes: >>> >>>> Fábio Santos writes: >>>> >>>>>

Re: semicolon at end of python's statements

treat a process a some more after loop things. It technically is not loop comprehension but just nested controls but by allowing them on the same line it looks close enough like loop comprehension. Plus if people have a problem that would best be solved by a while loop comprehension that would be just as easy. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list

Re: semicolon at end of python's statements

but when someone suggests a change that would allow him to structure his program more like how he sees it and indent levels are not short in supply, suggesting there is no problem, no matter how many one uses. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list

Re: Reading from stdin first, then use curses

din * The terminal in which it runs is a pseudo-terminal (pipe) * curses is not able to accept user input from the pseudo-terminal The question is: How do I read from stdin first and afterwards allow curses to read user input? Well you could close fd 0. Then open /dev/tty en dup the fd to 0.

Re: semicolon at end of python's statements

ition: | whatever which in python we can write: | elif condition: | whatever So either is seems this was a design mistake or a line and an indent level can be important enough to allow a combination of controls. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list

Re: semicolon at end of python's statements

Op 02-09-13 01:30, MRAB schreef: > On 01/09/2013 20:58, Antoon Pardon wrote: >> Op 31-08-13 02:09, Steven D'Aprano schreef: >>> On Fri, 30 Aug 2013 11:32:17 +0100, Fábio Santos wrote: >>> >> >>> >>> We really are spoiled for choice here. We

Re: semicolon at end of python's statements

Op 02-09-13 10:05, Steven D'Aprano schreef: > On Sun, 01 Sep 2013 21:58:15 +0200, Antoon Pardon wrote: > >> Op 31-08-13 02:09, Steven D'Aprano schreef: > >>> Adding a fourth option: >>> >>> for spam in sequence if predicate(spam): >>>

Re: semicolon at end of python's statements

Op 02-09-13 11:52, Steven D'Aprano schreef: > On Mon, 02 Sep 2013 10:29:05 +0200, Antoon Pardon wrote: > >> Why should we be more >> concerned with cascading ifs than with cascading controls in general? > > What cascading controls? > > for element in seq: >

Re: semicolon at end of python's statements

Op 02-09-13 12:42, Fábio Santos schreef: > On 09/02/2013 10:45 AM, Antoon Pardon wrote: >> Op 02-09-13 10:05, Steven D'Aprano schreef: >>> It doesn't keep a whole chain of >>> if clauses together. It doesn't let you do anything that you haven't

Re: semicolon at end of python's statements

ly because they identify their own way as the One True Way. And sure it can be a good thing to enforce a One True Way for a specific project or for all company code, but there is no need that all projects would need the same One True Way. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list

Re: UnicodeDecodeError issue

e FSR. > To take the problem the other way, one can take these > linguistic ascpects to illustrate the wrong design of > the FSR. No you can't, you are just assuming so because you feel it would confirm your bias against the FSR. -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list

Re: Reading from stdin first, then use curses

uld need to be queried by htop. If anyone could please point me in the right direction, I'd be very grateful Search for pty in the python documentation. -- Antoon Pardon. -- https://mail.python.org/mailman/listinfo/python-list

Re: Chardet, file, ... and the Flexible String Representation

sets". The problem? Not true. The FSR always uses the same coding. An "A" is always coded as 65. -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list

Re: Weighted choices

g a given fruit is proportional to its weight. In the example above, pears should appear twice as often as apples and kiwis should appear twice as often as bananas. Just a small question. Is a set of three bananas an acceptable outcome? -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list

Re: Weighted choices

Op 09-09-13 02:21, Dennis Lee Bieber schreef: > On Sun, 08 Sep 2013 19:48:55 +0200, Antoon Pardon > declaimed the following: > >> Op 08-09-13 04:12, Jason Friedman schreef: >>> choices = dict() >>> choices["apple"] = 10 >>> choices["p

Re: Weighted choices

Op 09-09-13 11:11, Steven D'Aprano schreef: > On Mon, 09 Sep 2013 09:12:05 +0200, Antoon Pardon wrote: > >> Op 09-09-13 02:21, Dennis Lee Bieber schreef: >>> On Sun, 08 Sep 2013 19:48:55 +0200, Antoon Pardon >>> declaimed the following: >>> &g

Re: Weighted choices

much as those present but not fielded, with an upper limit of double starting weight. Since the quarterbacks are fielded more, their weight will be less when you pick the rest of the team, so they will play less at other positions. Starting weights and adjustment will have to be picked by simulating a season and see what works. -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list

Re: Language design

in combination with negative indices. Take ls = range[10] What is the reverse of ls[a : b]? It is [b-1 : a-1: -1] Except of course when a == 0 or b == 0. -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list

Re: Language design

re surprising. > > Significant indentation. It gets someone every day, it seems. > Not only that. There are a lot of python code snippets on the net that for whatever reason lost their indentation. There is no algorithm that can restore the lost structure. -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list

Re: Language design

Op 13-09-13 12:13, Steven D'Aprano schreef: > On Fri, 13 Sep 2013 09:04:06 +0200, Antoon Pardon wrote: > >> Op 10-09-13 12:20, Chris Angelico schreef: >>> On Tue, Sep 10, 2013 at 4:09 PM, Steven D'Aprano >>> wrote: >>>> What design mistakes, tr

Re: Language design

portant difference because in the first case we mention a first while in the second case we mention b first is only illustrating his own confusion. And that is essentially what you are doing. -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list

Re: Tryign to send mail via a python script by using the local MTA

7;t you just ignore him, instead of showing us all that you too can contribute in a careless manner? -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list

Re: Tryign to send mail via a python script by using the local MTA

Op 16-09-13 09:44, Chris Angelico schreef: > On Mon, Sep 16, 2013 at 5:29 PM, Antoon Pardon > wrote: >> Op 16-09-13 03:52, Steven D'Aprano schreef: >>> Hi Nikos, >>> >>> I'm now going to put as much care and attention into my answer as you

Re: Tryign to send mail via a python script by using the local MTA

Op 16-09-13 09:46, Chris Angelico schreef: > On Mon, Sep 16, 2013 at 5:29 PM, Antoon Pardon > wrote: >> instead of showing us all that you >> too can contribute in a careless manner? > > Also: It takes effort to contribute usefully in a way that looks > careless :) I

Re: Tryign to send mail via a python script by using the local MTA

Op 16-09-13 10:19, Chris Angelico schreef: > On Mon, Sep 16, 2013 at 6:12 PM, Antoon Pardon > wrote: >> Op 16-09-13 09:46, Chris Angelico schreef: >>> On Mon, Sep 16, 2013 at 5:29 PM, Antoon Pardon >>> wrote: >>>> instead of showing us all that you &g

Re: Tryign to send mail via a python script by using the local MTA

Op 16-09-13 10:48, Chris Angelico schreef: > On Mon, Sep 16, 2013 at 6:43 PM, Antoon Pardon > wrote: >> Op 16-09-13 10:19, Chris Angelico schreef: >>> It's a contribution that SAYS that it looks carelessly written. I >>> think most people here are int

<    6   7   8   9   10   11   12   13   14   15   >