Re: Arithmetic with Boolean values
On 2012-08-12, Paul Rubin wrote: >> which can be simplified to: >> for x in range(len(L)//2 + len(L)%2): > > for x in range(sum(divmod(len(L), 2))): ... nice solution. Bernd -- "Die Antisemiten vergeben es den Juden nicht, dass die Juden Geist haben - und Geld." [Friedrich Nietzsche] -- http://mail.python.org/mailman/listinfo/python-list
Re: Appending to []
On 2012-04-20, Rotwang wrote:
> since a method doesn't assign the value it returns to the instance on
> which it is called; what it does to the instance and what it returns are
> two completely different things.
Returning a None-value is pretty useless. Why not returning self, which would be
the resulting list in this case? Returning self would make the
language a little bit more functional, without any drawback.
Then nested calls like
a = [].append('x').append('y').append('z')
would be possible with a containing the resulting list
['x', 'y', 'z'].
That is the way I expect any append to behave.
Bernd
--
"Die Antisemiten vergeben es den Juden nicht, dass die Juden Geist
haben - und Geld." [Friedrich Nietzsche]
--
http://mail.python.org/mailman/listinfo/python-list
Re: why () is () and [] is [] work in other way?
On 2012-04-20, dmitrey wrote: > I have spent some time searching for a bug in my code, it was due to > different work of "is" with () and []: () is () > True You should better not rely on that result. I would consider it to be an implementation detail. I may be wrong, but would an implementation that results in () is () ==> False be correct or is the result True really demanded by the language specification? [] is [] > False Same for that. > > (Python 2.7.2+ (default, Oct 4 2011, 20:03:08) > [GCC 4.6.1] ) > > Is this what it should be or maybe yielding unified result is better? See above. Bernd -- "Die Antisemiten vergeben es den Juden nicht, dass die Juden Geist haben - und Geld." [Friedrich Nietzsche] -- http://mail.python.org/mailman/listinfo/python-list
Re: Appending to []
On 2012-04-21, Kiuhnm wrote:
>> Returning a None-value is pretty useless. Why not returning self, which
>> would be
>> the resulting list in this case? Returning self would make the
>> language a little bit more functional, without any drawback.
>>
>> Then nested calls like
>>
>> a = [].append('x').append('y').append('z')
>
> You just answered to your own question: append returns None so that
> people can't use it the way you did.
That is one possible way to design the method, but not the only
possible way.
> You make the reader believe that you're adhering to the functional
> paradigm whereas 'append' has actually side effects!
> Moreover, you use an assignment just to reinforce this wrong belief.
I know about side effects and I know that letting append return self
would not make Python a purely functional language with only immutable
data.
I just asked a simple question about a detail I personally would
consider it to be useful.
Please no further religious war about that ;-)
Bernd
--
"Die Antisemiten vergeben es den Juden nicht, dass die Juden Geist
haben - und Geld." [Friedrich Nietzsche]
--
http://mail.python.org/mailman/listinfo/python-list
Re: Appending to []
On 2012-04-21, Kiuhnm wrote:
> Sorry if I wasn't clear. I meant that one should either relies on
> side-effects and write something like
>a.append('x').append('t').append('z')
> or use a more functional style and write
>a = a + [x] + [z]
> Mixing the two doesn't seem very elegant to me.
> I also think that if you need to repeatedly modify an object in the same
> expression, then you should prefer the more functional approach.
> I wasn't suggesting that you didn't know what functional programming and
> side effects are.
> Mine was a justification (maybe opinable) of why append was designed
> that way.
Ok, understood and accepted
Bernd
--
"Die Antisemiten vergeben es den Juden nicht, dass die Juden Geist
haben - und Geld." [Friedrich Nietzsche]
--
http://mail.python.org/mailman/listinfo/python-list
Re: why () is () and [] is [] work in other way?
On Sat, Apr 21, 2012 at 03:43:03PM -0400, Dave Angel wrote: > On 04/21/2012 09:48 AM, Bernd Nawothnig wrote: > > On Sat, Apr 21, 2012 at 09:21:50AM -0400, Dave Angel wrote: > >>>>>>> [] is [] > >>>> False > >>> Same for that. > >> > >> Here I have to disagree. If an implementation reused the list object > >> for two simultaneously-existing instances, it would violate first > >> principles. > > > > Hm. > > > > Even if there is no chance to reach any of these two lists after the > > comparison because *no* references to them exist and both *must* be > > identical because they are both noted as the same literals? > > > > If any references exist, no question, that is pretty clear and > > understandable. But in that special case? > > > > You forgot to CC the list on your two messages to me. Sorry, I'm reading the list via usenet gateway. Hopefully it works now. > Clearly, False has to be a valid return result. So I assume your > question is why shouldn't an implementation be permitted to return True, > in other words why couldn't it be ambiguous, like the immutable case. Yes. > Why would you (a hypothetical compiler writer) write an optimizer to > look for such a special case like this, when the code would probably > never appear in a real program, and certainly not in a performance > critical portion of one. > And if you did write one, why would you have it produce a different > result than the non-optimized version? Why not have it return 42 if > that's the goal? My original statement was: don't rely on such behaviour, it is an implementation detail. Your argument above was: it would violate first principles. And I still don't see that point. The comparison [] is [] maybe totally useless, of course, but which first principle would be violated by a compiler that lets that expression evaluate to True? Where can I read that the result *must* be False? Otherwise it is simply an ambigious and not clearly defined expression like () is () Bernd -- http://mail.python.org/mailman/listinfo/python-list
Re: Appending to []
On 2012-04-22, Steven D'Aprano wrote:
> On Sat, 21 Apr 2012 14:48:44 +0200, Bernd Nawothnig wrote:
>
>> On 2012-04-20, Rotwang wrote:
>>> since a method doesn't assign the value it returns to the instance on
>>> which it is called; what it does to the instance and what it returns
>>> are two completely different things.
>>
>> Returning a None-value is pretty useless. Why not returning self, which
>> would be the resulting list in this case? Returning self would make the
>> language a little bit more functional, without any drawback.
>
> It is a deliberate design choice, and there would be a drawback.
>
> A method like append could have three obvious designs:
>
> 1) Functional, no side-effects: return a new list with the item appended.
>
> 2) Functional, with side-effect: return the same list, after appending
> the item.
>
> 3) Procedural, with side-effect: append the item, don't return anything
> (like a procedure in Pascal, or void in C).
Correct.
> Python chooses 3) as the design, as it is the cleanest, most pure choice
> for a method designed to operate by side-effect. Unfortunately, since
> Python doesn't have procedures, that clean design is slightly spoilt due
> to the need for append to return None (instead of not returning anything
> at all).
>
> How about 1), the pure functional design? The downside of that is the
> usual downside of functional programming -- it is inefficient to
> duplicate a list of 100 million items just to add one more item to that
> list.
In general I always prefer the pure functional approach. But you are
right, if it is too costly, one has to weigh the pros and contras.
> Besides, if you want a pure functional append operation, you can
> simply use mylist + [item] instead.
That ist true. I will keep that in mind :-)
> But what about 2), the mixed (impure) functional design? Unfortunately,
> it too has a failure mode: by returning a list, it encourages the error
> of assuming the list is a copy rather than the original:
>
> mylist = [1, 2, 3, 4]
> another_list = mylist.append(5)
> # many pages of code later...
> do_something_with(mylist)
Yes, but mutable data is in general a candidate for unexpected
behaviour, regardless wether you use an impure functional notation or
not:
mylist = [1, 2, 3, 4]
mylist.append(5)
another_list = mylist
# many pages of code later...
do_something_with(mylist)
avoids that impure function call but can perfectly lead to the same
unexpected behaviour. Your "many pages of code later" and that it is
simply difficult or impossible to keep in mind all these possible
state changes of variables is the real problem here.
> This is especially a pernicious error because instead of giving an
> exception, your program will silently do the wrong thing.
>
> "I find it amusing when novice programmers believe their main
> job is preventing programs from crashing. More experienced
> programmers realize that correct code is great, code that
> crashes could use improvement, but incorrect code that doesn’t
> crash is a horrible nightmare."
> -- Chris Smith
Absolutely corrrect!
> Debugging these sorts of bugs can become very difficult, and design 2) is
> an attractive nuisance: it looks good because you can chain appends:
>
> mylist.append(17).append(23).append(42)
> # but why not use mylist.extend([17, 23, 42]) instead?
>
> but the disadvantage in practice far outweighs the advantage in theory.
>
> This is the same reason why list.sort, reverse and others also return
> None.
Yeah, understood.
>> Then nested calls like
>>
>> a = [].append('x').append('y').append('z')
>>
>> would be possible with a containing the resulting list
>>
>> ['x', 'y', 'z'].
>>
>> That is the way I expect any append to behave.
>
> That would be possible, but pointless. Why not use:
>
> a = ['x', 'y', 'z']
>
> directly instead of constructing an empty list and then make three
> separate method calls? Methods which operate by side-effect but return
> self are an attractive nuisance: they seem like a good idea but actually
> aren't, because they encourage the user to write inefficient, or worse,
> incorrect, code.
In the past I often wrote methods that returned self instead of void,
None, or Nil depending on the used language.
But your arguments against that are not bad.
Thanks!
Instead of thinking about impure designs I should dig deeper into
Haskell :-)
Bernd
--
"Die Antisemiten vergeben es den Juden nicht, dass die Juden Geist
haben - und Geld." [Friedrich Nietzsche]
--
http://mail.python.org/mailman/listinfo/python-list
Re: why () is () and [] is [] work in other way?
On 2012-04-23, Paul Rubin wrote: > Kiuhnm writes: >> I can't think of a single case where 'is' is ill-defined. > > If I can't predict the output of > > print (20+30 is 30+20) # check whether addition is commutative > print (20*30 is 30*20) # check whether multiplication is commutative > > by just reading the language definition and the code, I'd have to say > "is" is ill-defined. "is" was never designed for comparing literals or expressions. the expression 20+30 is 30+20 maybe syntactically correct but is nevertheless pretty senseless and you can, of course, not check commutativity with it. For checking commutativity you have to use: 20+30 == 30+20 > >> You're blaming 'is' for revealing what's really going on. 'is' is >> /not/ implementation-dependent. It's /what's going on/ that's >> implementation-dependent. >> "a is b" is true iff 'a' and 'b' are the same object. Why should 'is' >> lie to the user? > > Whether a and b are the same object is implementation-dependent. >>> a = something >>> b = a >>> a is b True Should be guaranteed and implementation-independent. Bernd -- "Die Antisemiten vergeben es den Juden nicht, dass die Juden Geist haben - und Geld." [Friedrich Nietzsche] -- http://mail.python.org/mailman/listinfo/python-list
Re: Detect Linux Runlevel
On 2016-12-05, Wildman wrote: > And I am trying to write it without using external programs, where > possible. That is not the Unix way. > I am a hobby programmer and I've been trying to learn python > for a few months now. The program is 'worthlessware' but it > is a 'learning experience' for me. It looks for me like a worthless learning experience. > A friend wrote a similar program in Bash script and I have been > working on translating it to Python. Stay with shell script for such tasks. It is never a good idea to choose the programming language before closer evaluating the problem. Bernd -- No time toulouse -- https://mail.python.org/mailman/listinfo/python-list
Re: topology rules in python
On 2016-12-20, Xristos Xristoou wrote: > I have a PostGIS database with shapefiles lines, polygons and points > and I want to create a topology rules with python. Any idea how to do > that ?some packages ? http://www.gdal.org/ or: pip install gdal Bernd -- no time toulouse -- https://mail.python.org/mailman/listinfo/python-list
Re: Python slang
On 2016-08-06, Chris Angelico wrote: > On Sat, Aug 6, 2016 at 11:14 AM, Steven D'Aprano > wrote: >>> I don't ask about `None` instead of `null` because I suppose here it's >>> a matter of disambiguation (null, in many languages, is not equal to >>> null). >> >> Really? Which languages? That's not true in Pascal, C, Ruby or >> Javascript. >> > > SQL (shown here with PostgreSQL's CLI): > > rosuav=> \pset null NULL > Null display is "NULL". > rosuav=> select NULL = NULL; > ?column? > -- > NULL > (1 row) > > But SQL's NULL is a cross between C's NULL, IEEE's NaN, Cthulhu, and > Emrakul. SQL NULL has the semantic of "unknown". So if one or both operands of a comparison (or any other operation) are unknown the result is unknown too. And that means NULL. That is also the reason why you have the keyword STRICT when declaring a function in PostgreSQL. If only one parameter of the function is NULL and the result depends directly on the parameter the planner can then automatically skip the function call completely und replace the result by NULL without any need to analyse or enter the function body. Bernd -- no time toulouse -- https://mail.python.org/mailman/listinfo/python-list
Re: Python slang
On 2016-08-06, Chris Angelico wrote: > On Sun, Aug 7, 2016 at 5:37 AM, Bernd Nawothnig > wrote: >>> But SQL's NULL is a cross between C's NULL, IEEE's NaN, Cthulhu, and >>> Emrakul. >> >> SQL NULL has the semantic of "unknown". So if one or both operands of >> a comparison (or any other operation) are unknown the result is >> unknown too. And that means NULL. > > That's not entirely accurate, and it doesn't explain why NULL > sometimes behaves as if it's a genuine value, and sometimes as if it's > completely not there. For instance, taking the average of a column of > values ignores NULLs completely, and COUNT(column) is the same as > COUNT(column) WHERE column IS NOT NULL; but in some situations it > behaves more like NaN: > > rosuav=> select null or true, null or false, null and true, null and false; > ?column? | ?column? | ?column? | ?column? > --+--+--+-- > t| NULL | NULL | f > (1 row) > > Anything "or true" has to be true, so NULL OR TRUE is true. And then > there are the times when NULL acts like a completely special value, > for instance in a foreign key - it means "there isn't anything on the > other end of this relationship", and is perfectly legal. Or in a > SELECT DISTINCT, where NULL behaves just like any other value - if > there are any NULL values in the column, you get back exactly one NULL > in the result. Thanks for that additions and corrections. Bernd -- no time toulouse -- https://mail.python.org/mailman/listinfo/python-list
Re: Reading csv file
On 2013-12-17, Igor Korot wrote: > Hi, ALL, > Is there a better way to do that: > > def Read_CSV_File(filename): > file = open(filename, "r") > reader = csv.DictReader(file) > line = 1 > for row in reader: > if line < 6: > reader.next() > line++ > # process the CSV #v+ def Read_CSV_File(filename): with open(filename) as f: for line,row in enumerate(csv.DictReader(f)): if line >= 6: # process the CSV #v- Bernd -- no time toulouse -- https://mail.python.org/mailman/listinfo/python-list
Re: Remove comma from tuples in python.
On 2014-02-21, Mircescu Andrei wrote: > vineri, 21 februarie 2014, 08:49:01 UTC+2, Jaydeep Patil a scris: >> I am getting below tuple from excel. >> >> How should i remove extra commas in each tuple to make it easy for >> operations. >> >> >> >> tuples is: >> >> seriesxlist1 = ((0.0), (0.01), (0.02), (0.03), (0.04), (0.05), (0.06), >> (0.07), (0.08), (0.09), (0.1), (0.11)) > > i think you have a tuple of tuples there. a tuple of 12 tuples. No it isn't: #v+ >>> a = ((0.0), (0.01), (0.02), (0.03), (0.04), (0.05), (0.06), (0.07), (0.08), >>> (0.09), (0.1), (0.11)) >>> a (0.0, 0.01, 0.02, 0.03, 0.04, 0.05, 0.06, 0.07, 0.08, 0.09, 0.1, 0.11) #v- The comma makes a tuple, not the parenthesis alone: #v+ >>> a = ((0.0,), (0.01,), (0.02,), (0.03,), (0.04,), (0.05,), (0.06,), (0.07,), >>> (0.08,), (0.09,), (0.1,), (0.11,)) >>> a ((0.0,), (0.01,), (0.02,), (0.03,), (0.04,), (0.05,), (0.06,), (0.07,), (0.08,), (0.09,), (0.1,), (0.11,)) >>> #v- Bernd -- no time toulouse -- https://mail.python.org/mailman/listinfo/python-list
Re: why indentation should be part of the syntax
On 2014-03-02, Stefan Behnel wrote: > Haven't seen any mention of it on this list yet, but since it's such an > obvious flaw in quite a number of programming languages, here's a good > article on the recent security bug in iOS, which was due to accidentally > duplicated code not actually being as indented as it looked: > > https://www.imperialviolet.org/2014/02/22/applebug.html The way Perl or Go handles it where it is not possible to omit the curly braces would have prevented the same error too. Bernd -- no time toulouse -- https://mail.python.org/mailman/listinfo/python-list
Re: "Backward"-Iterator - Beginners question
On 2013-10-31, Ulrich Goebel wrote: > I'm locking for an "iterator" type with not only the .next() method, but > with a .previous(), .first() and .last() method, so that I can through > it from the beginning or from the end, and in both directions, even > alternately (for example two steps forward, one backward, two steps > forward). Simply write a class with these methods. Where is the problem? Bernd -- no time toulouse -- https://mail.python.org/mailman/listinfo/python-list
Re: What is the state of MySQL support for Python 3?
On 2014-06-24, haiz...@gmail.com wrote: > I'm starting a new project from scratch so I think its finally a time > to switch to the latest and greatest Python 3.4. > > But I'm puzzled with MySQL support for Python 3. So far the only > stable library I've found it pymysql. > > All others are either abandoned work-in-progress projects or do not > support Python 3: > * mysqldb - Python 2.x only > * mysql-ctypes - Python 2.x only > * amysql - Python 2.x only > * ultramysql - Python 2.x only > * MySQL Connector/Python - new guy in block. Does anyone use it? Yes. It comes directly from MySQL and is written in pure Python. For that it may not be the fastest solution but it works. Tested with Python 3.2 Bernd -- no time toulouse -- https://mail.python.org/mailman/listinfo/python-list
Re: How to get Timezone from latitude/longitude ?
On 2014-06-25, codetars...@gmail.com wrote: > I'm looking for a python-library which can help me to get Timezone and > Timezone-offset(UTC) from latitude/longitude. > > I'm not able to find an easy way to do it. You can find the data as a zipped shapefile here: http://efele.net/maps/tz/world/ Download the data and use pyshp and/or gdal/ogr for the lookup. It may not be as simple as you wanted it to be, but it is possible. Bernd -- no time toulouse -- https://mail.python.org/mailman/listinfo/python-list
Re: global lists
On 2005-05-08, andrea crotti wrote: > I have a little "problem", I don't understand the reason of this: > a = [10,1,2,3] > def foo(): > global a > for el in a: > el = el*2 Simple data types (as integer) are _not_ implemented as references as you obviously expected. Instead el is copied by value from each a[n]. Thus you only changed temporary copies. The whole list instead _is_ a reference. If you write b = a b[0] = 57 a[0] will be effected too. > This doesn't make any difference, if I do > def foo(): > global a > a[0] = 4 That should alter a[0]. > But > > def foo(): > global a > for n in range(len(a)): > a[n] = a[n]*2 > > Doesn't work either... It does. Test it again. Bernd -- Those who desire to give up freedom in order to gain security, will not have, nor do they deserve, either one. [T. Jefferson] -- http://mail.python.org/mailman/listinfo/python-list
Re: A new to Python question
On 2005-05-14, David wrote: > abc(x,y,dotp,sumx,maxv) (x,y,dotp,sumx,maxv) = abc(x,y,dotp,sumx,maxv) Bernd -- Those who desire to give up freedom in order to gain security, will not have, nor do they deserve, either one. [T. Jefferson] -- http://mail.python.org/mailman/listinfo/python-list
Re: A new to Python question
On 2005-05-14, Philippe C. Martin wrote: > You're thinking you're passing the arguments as reference That is the way Fortran handles them: [...] >> Right now I'm taking a simple program I wrote in Fortran Bernd -- Those who desire to give up freedom in order to gain security, will not have, nor do they deserve, either one. [T. Jefferson] -- http://mail.python.org/mailman/listinfo/python-list
Re: A new to Python question
> On 2005-05-14, M.E.Farmer wrote: > (x,y,dotp,sumx,maxv) = abc(x,y,dotp,sumx,maxv) > This will only create a tuple in memory that has no name to reference > it by! Maybe. But it does not seem to hurt. And I am not sure the tupel _is_ really created in that situation. > How would you access the returned value? > If you want a tuple you need to assign all the return vales to a single > name. We do not want the tuple. Python 2.3.5 (#1, Apr 28 2005, 12:14:04) [GCC 3.4.3-20050110 (Gentoo Linux 3.4.3.20050110-r2, ssp-3.4.3.20050110-0, pie- on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> def foo(): >>> ... return 1,2,3 >>> ... >>> (a,b,c)=foo() >>> print a,b,c 1 2 3 >>> works. Of course, you can omit the (): >>> a,b,c=foo() >>> print a,b,c 1 2 3 That makes no difference. Bernd -- Those who desire to give up freedom in order to gain security, will not have, nor do they deserve, either one. [T. Jefferson] -- http://mail.python.org/mailman/listinfo/python-list
Re: A new to Python question
On 2005-05-14, M.E.Farmer wrote: > I explained what i meant in previous post there was nothing more than > just a discussion No. You claimed This will only create a tuple in memory But we just learned that this is not the case. > I have no real problem here just more of a sore point in style for > me. I feel that parens are quite overloaded and it can be confusing > to newbies. But if the parens are just fluff then get rid of them, it > is clearer * at least to me * ;) Reduced to this argument I have no objection. > There are enough things wrapped in parens nowadays it is starting to > look like lisp. Lisp is far from being ugly ;-) Bernd -- Those who desire to give up freedom in order to gain security, will not have, nor do they deserve, either one. [T. Jefferson] -- http://mail.python.org/mailman/listinfo/python-list
Re: Schily ueber Deutschland
On 2005-05-15, [EMAIL PROTECTED] wrote: > Lese selbst: > http://www.heise.de/newsticker/meldung/59427 Ja, schlimm. Trotzdem ist das hier a) eine englischsprachige NG und b) geht es hier um die Programmiersprache Python Lass es also bitte endlich! Bernd -- Those who desire to give up freedom in order to gain security, will not have, nor do they deserve, either one. [T. Jefferson] -- http://mail.python.org/mailman/listinfo/python-list
Re: A new to Python question
On 2005-05-15, M.E.Farmer wrote: >> No. You claimed > > This will only create a tuple in memory > > That is not what I said please do not edit my words and call it a > quote! Again the whole sentence: Message-ID: <[EMAIL PROTECTED]> | This will only create a tuple in memory that has no name to reference | it by! Please check it out. I did only cut the sentence. But that did not change the sense of the part I quoted. (As I understood it, correct me if I'm wrong, I'm not a native English speaker). >> But we just learned that this is not the case. > Yes it seems I was proven wrong and have learned much from the > discussion ;) That is why I am here to learn from others and help if > I can ( sometimes I am just plain wrong and I get the help ) I know that very well. I often learned much from such discussions too. >> Reduced to this argument I have no objection. > Glad to hear it. >> Lisp is far from being ugly ;-) > Your words not mine.I never said it was ugly. > Lisp is beautiful but Python isn't Lisp, and the () *are* getting > overloaded. Understood and accepted. Bernd -- Those who desire to give up freedom in order to gain security, will not have, nor do they deserve, either one. [T. Jefferson] -- http://mail.python.org/mailman/listinfo/python-list
Re: German spam event [was: Re: Schily ueber Deutschland]
On 2005-05-16, François Pinard wrote: >> I don't think that post was really from MAL. It seems to be a >> sporgery attack on the newsgroup. Sigh. > For the last two days, I receive quite an amount of robotic rejects, > after my name was used as the forged From: Same with me after my follow-up. [...] > Such forged From appears all the time as far as I am concerned, and > had for years now. But something significant happened this weekend. Looks like another windows worm. Now they seem to come with a more sofisticated 'payload'. I am sure that will increase in the future. It is just the beginning ... Bernd -- Software is like sex: it's better when it's free [Linus Torvalds] -- http://mail.python.org/mailman/listinfo/python-list
Re: newbie - variable "buried in quotes"
On 2005-05-16, plsullivan wrote:
> I've got a variable deep inside some quotes needed by the application I
> am using. I can't figure out how to make this work. (Also, is there a
> line continuation character?)
> luser = win32api.GetUserName()
> gp.FeatureclassToCoverage_conversion("'Database
> [EMAIL PROTECTED]'
> POLYGON", prcl83, "", "DOUBLE") % luser
You poosibly meant something like that:
#v+
gp.FeatureclassToCoverage_conversion("'Database"
"[EMAIL PROTECTED]'"
"POLYGON" % luser, prcl83, "", "DOUBLE")
#v-
Bernd
--
Those who desire to give up freedom in order to gain security,
will not have, nor do they deserve, either one. [T. Jefferson]
--
http://mail.python.org/mailman/listinfo/python-list
Re: newbie - variable "buried in quotes"
On 2005-05-16, plsullivan wrote: > If I follow your response Bernd, it looks like you interpreted that as > several lines. It actually should all be on one line. That's what made > me wonder if there is a line continuation character. The lines are concatenated to one string as I wrote it. See also fup from Peter Hansen for more explanations. Bernd -- Those who desire to give up freedom in order to gain security, will not have, nor do they deserve, either one. [T. Jefferson] -- http://mail.python.org/mailman/listinfo/python-list
Re: newbie - variable "buried in quotes"
On 2005-05-16, plsullivan wrote:
> Thanks guys but I am still not getting it. This part -->
> gp.FeatureclassToCoverage_conversion("'Database
> [EMAIL PROTECTED]'
> POLYGON", prcl83, "", "DOUBLE") <-- % luser is one long command.
Yes, I understood you perfectly well.
> I need to be able to insert the luser variable deep in the middle of
> that.
luser will replace the '%s' in my version. Just try it!
Bernd
--
Those who desire to give up freedom in order to gain security,
will not have, nor do they deserve, either one. [T. Jefferson]
--
http://mail.python.org/mailman/listinfo/python-list
Re: Recommended version of gcc for Python?
On 2005-05-16, Dave Kuhlman wrote: > Is there a recommended version of gcc that I should be using to > compile Python? I've compiled Python 2.4 with gcc 3.3.4 on Ubuntu > Debian GNU/Linux. However, I notice that gcc 3.5 and gcc 4.0 are > available for installation. I am on Gentoo Linux and use gcc 3.4.3 (~x86 == unstable) for almost all ebuilds including Python 2.3.5 (x86 == stable). No malfunction so far, and Gentoo depends heavily on Python. _If_ gcc 3.4 compiles a source the resulting binary will work. The only problem is, not all ebuilds compile without errors using gcc 3.4. Simply try it. Bernd -- Those who desire to give up freedom in order to gain security, will not have, nor do they deserve, either one. [T. Jefferson] -- http://mail.python.org/mailman/listinfo/python-list
Re: Empty string is False right?
On 2009-01-31, AJ Ostergaard wrote:
> Thanks for that but why:
'' and True
> ''
> Surely that should be False?!?
It is:
#v+
>>> bool('' and True)
False
#v-
Bernd
--
No time toulouse
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python Command Line Arguments
On 2017-04-13, Jason Friedman wrote: >> I have this code which I got from https://www.tutorialspoint. >> com/python/python_command_line_arguments.htm The example works fine but >> when I modify it to what I need, it only half works. The problem is the >> try/except. If you don't specify an input/output, they are blank at the end >> but it shouldn't be. >> >> import getopt >> import sys > > I am guessing you are wanting to parse command-line arguments rather than > particularly wanting to use the getopt module. > If I am correct you might want to spend your time instead learning the > argparse module: > https://docs.python.org/3/library/argparse.html > https://docs.python.org/3/howto/argparse.html He should switch to argparse in any case because getopt is no longer supported and does only receive bugfixes. Bernd -- Die Antisemiten vergeben es den Juden nicht, dass die Juden ‘Geist’ haben – und Geld. Die Antisemiten – ein Name der ‘Schlechtweggekommenenen’ [Friedrich Nietzsche] -- https://mail.python.org/mailman/listinfo/python-list
Re: "Goto" statement in Python
On 2017-04-13, Mikhail V wrote: > On 13 April 2017 at 18:48, Ian Kelly wrote: >> On Thu, Apr 13, 2017 at 10:23 AM, Mikhail V wrote: >>> Now I wonder, have we already collected *all* bells and whistles of Python >>> in these two examples, or is there something else for expressing trivial >>> thing. >> >> Functions and exceptions are considered "bells and whistles"? > > You mean probably classes and exceptions? For me, indeed they are, > but it depends. > > And breaking the code into def() chunks that are not > functions but just chunks... I don't know, looks bad. Organising code in a bunch of small functions is by far better coding style and better readable than put it all together in one chunk. And that holds for all programming languages, not only for Python. Bernd -- Die Antisemiten vergeben es den Juden nicht, dass die Juden ‘Geist’ haben – und Geld. Die Antisemiten – ein Name der ‘Schlechtweggekommenenen’ [Friedrich Nietzsche] -- https://mail.python.org/mailman/listinfo/python-list
Re: "Goto" statement in Python
On 2017-04-13, Grant Edwards wrote:
> On 2017-04-13, Rob Gaddi wrote:
>
>> No, C doesn't support exception handling. As a result, handling error
>> conditions in C is a huge pain for which (forward-only) goto is often,
>> while not the only remedy, the least painful one.
>
> Indeed. That is almost the only place I use 'goto' in C, and the
> almost the only place I see others use it. Very occasionally, you see
> a the error handling goto refactored into a backwards "goto retry":
>
> this code
>
> foo()
> {
> while (1)
> {
>
> if ()
>goto error:
>
> return;
>
> error:
>
> }
> }
foo()
{
int done = 0;
while (! done)
{
if () {
} else {
done = 1;
}
}
Bernd
--
Die Antisemiten vergeben es den Juden nicht, dass die Juden ‘Geist’
haben – und Geld. Die Antisemiten – ein Name der
‘Schlechtweggekommenenen’ [Friedrich Nietzsche]
--
https://mail.python.org/mailman/listinfo/python-list
