What encoding is used when initializing sys.argv?
Hi, When solving the problem of passing the unicode directory name through command line into a script (MS Windows environment), I have discovered that I do not understand what encoding should be used to convert the sys.argv into unicode. I know about the rejected attempt to implement sys.argvu. Still, how the sys.argv is filled? What encoding is used when parsing the cmd line internally? To what encoding is it converted when non ASCII characters appear? Thanks for your time and experience, pepr -- Petr Prikryl (prikrylp at skil dot cz) -- http://mail.python.org/mailman/listinfo/python-list
Re: What encoding is used when initializing sys.argv?
Thanks, Martin v. Löwis, Neil Hodgson, and Tim Roberts. I really appreciate your valuable comments. It simply works. Thanks again, Petr "Neil Hodgson" wrote... > Petr Prikryl: > > > I do not understand what encoding should be used > > to convert the sys.argv into unicode. > > Martin mentioned CP_ACP. In Python on Windows, this > can be accessed as the "mbcs" codec. > > import sys > print repr(sys.argv[1]) > print repr(unicode(sys.argv[1], "mbcs")) > > C:\bin>python glurp.py abcß* > 'abc\xdf\x95' > u'abc\xdf\u2022' > > Neil -- http://mail.python.org/mailman/listinfo/python-list
Any 3state Check Tree Ctrl for wxPython available?
Hi, I am experimenting with wxPython on Windows box. What I need to implement is a check tree control with 3 states for each checkbox: unchecked, checked, gray checked. The status of the checkbox should reflect the status of the children. When ALL children are checked, then the status should be checked. When NO children are checked, the status should be unchecked. When SOME children are selected, the status should be checked with gray background. I have found something else that could be valuable after I start understand that: http://mitglied.lycos.de/drpython/CheckTreeCtrl.tar Anyway, is there something similar with 3 states available around? Thanks for your time and experience, pepr -- Petr Prikryl (prikrylp at skil dot cz) -- http://mail.python.org/mailman/listinfo/python-list
Bug in Python 2.4 raw_input(u'xyz') Win/command line?
Hi,
Could you test the following example for your
non-English language with accented characters?
I have observed a problem when running
Python 2.4, Windows version (python-2.4.msi)
and using raw_input() with unicode prompt
string in a console program (ran in the DOS window).
I do use the following sitecustomize file to set
the default encoding:
sitecustomize.py
=
import sys
sys.setdefaultencoding('cp1250')
=
test.py
=
# -*- coding: cp1250 -*-
s = u'string with accented letters'
print s # OK
val = raw_input(s)# s displayed differently (wrong)
=
... when run in a DOS window. See the attached
test.png. The "type test.py" displays the string
definition also wrong, because the DOS window
uses different encoding than cp1250. The print
command prints the string correctly, converting
the internal unicode string to the encoding that
the is defined by the output environment. However,
the raw_input() probably does convert the unicode
string to the cp1250 and does not do the same
(more clever) thing that the print does.
Could you confirm the bug? Is it known?
Should this be posted into some bug-report list?
Petr
python test.py
I have observed t
--
Petr Prikryl (prikrylp at skil dot cz)
test.py
Description: test.py
<>--
http://mail.python.org/mailman/listinfo/python-list
Re: list item's position
> On Wed, 19 Jan 2005 22:04:44 -0500, Bob Smith wrote: > > [...] how to find an element's numeric value (0,1,2,3...) > > in the list. Here's an example of what I'm doing: > > > > for bar in bars: > > if 'str_1' in bar and 'str_2' in bar: > >print bar > > > > This finds the right bar, but not its list position. The reason I need > > to find its value is so I can remove every element in the list before it > > so that the bar I found somewhere in the list becomes element 0... does > > that make sense? I have borrowed the bars list example from "Bill Mill"s solutions and here are the two solutions... bars = ['str', 'foobaz', 'barbaz', 'foobar'] # Solution 1: The enumerate(). for idx, bar in enumerate(bars): if 'bar' in bar and 'baz' in bar: break bars_sliced = bars[idx:] print bars_sliced # Solution 2: Low level approach, testing and removing combined. In situ. while bars: # some prefer len(bars) > 0, which is less magical, IMHO bar = bars.pop(0) # get and remove the first element if 'bar' in bar and 'baz' in bar: bars.insert(0, bar) # insert the tested back break # and finish print bars The result is ['barbaz', 'foobar'] in both cases. Petr -- Petr Prikryl (prikrylp at skil dot cz) -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] Good C++ book for a Python programmer
Try also the Bruce Eckel's "Thinking in C++". It is also available on-line for free at http://www.mindview.net/Books/TICPP/ThinkingInCPP2e.html I like the book because it explains the things very clearly. After reading it, one will stop to think and say that C++ is "only C with strange OO things on the top". Petr "Paul Rubin" wrote in message news:<[EMAIL PROTECTED]>... > "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes: > > I was wondering whether anyone could recommend a good C++ book, with > > "good" being defined from the perspective of a Python programmer. I > > realize that there isn't a book titled "C++ for Python Programmers", > > but has anyone found one that they think goes particularly well with > > the Python way? > > I think it's not possible to really grok C++ without having worked on > large multi-person C projects and understood what problems C++ tried > to solve. The only good book I know about C++ is by Stroustrup, "The > C++ Programming Language" or something like that; it's not an easy > book though. -- http://mail.python.org/mailman/listinfo/python-list
Simpler transition to PEP 3000 "Unicode only strings"?
Hi all, My question is: How do you tackle with mixing Unicode and non-Unicode parts of your application? Context: The PEP 3000 says "Make all strings be Unicode, and have a separate bytes() type." Until then, I am forced to write # -*- coding: cp123456 -*- (see 2.1.4 Encoding declarations) and use... myString = u'text with funny letters' This leads to a source polution that will be difficult to remove later. The idea: = What do you think about the following proposal that goes the half way If the Python source file is stored in UTF-8 (or other recognised Unicode file format), then the encoding declaration must reflect the format or can be omitted entirely. In such case, all simple string literals will be treated as unicode string literals. Would this break any existing code? Thanks for your time and experience, pepr -- Petr Prikryl (prikrylp at skil dot cz) -- http://mail.python.org/mailman/listinfo/python-list
Suggestion for "syntax error": ++i, --i
Hi, Summary: In my opinion, the C-like prefix increment and decrement operators (++i and --i) should be marked as "syntax error". Current situation: try... (Python 2.4 (#60, ...)) >>> i = 1 >>> i 1 >>> i++ File "", line 1 i++ ^ SyntaxError: invalid syntax >>> ++i 1 >>> --i 1 >>> Reason for how ++i and --i behaves in Python is that it is probably treated as (-(-i)) and (+(+i)) respectively. Rationale: My guess is that many Python users do use other languages at the same time. The C-family languages do use the prefix increment and decrement operators. When used in Python no warning appears -- the code simply does not work as expected. In the same time, there is probably no reason to use the increment and decrement prefix operators. On the other hand, the newcommer or the programmer that "types ++i automatically because of brain synapses say he/she should..." is not warned until something does not work. Con: The situation must be recognized by the parser (i.e. someone have to implement it). Pro: No runtime overhead except of the detection of the situation. As Python is a good candidate to be used as the language for teaching, the "syntax error" would be the pedagogical plus. Personal experience: Many things in Python work intuitively. My C++ experience "forced me" to use ++i as described above. I use iteration more these days and I know about the ++i problem invisibility in Python. But I had to learn by mistake. The ++i behaviour is not intuitive for me. Your opinion? -- Petr Prikryl (prikrylp at skil dot cz) -- http://mail.python.org/mailman/listinfo/python-list
Re: Suggestion for "syntax error": ++i, --i
Hi Christian, The suggestion is to mark PREFIX version ++i as syntax error. It is not related to the postfix version of the ++ operator. For prefix in/decrement, there is no extra variable behind. But again, it is not related to the suggestion. The postfix version is already marked as "syntax error". The suggestion is to do the same with the prefix version of the operators that are not used in Python. Petr "Christian Ergh" wrote... > Hmm, i never liked the i++ syntax, because there is a value asignment > behind it and it does not show - except the case you are already used to it. > > >>> i = 1 > >>> i +=1 > >>> i > 2 > > I like this one better, because you see the assignment at once, it is > easy to read and inuitive usability is given - in my opinion. > Chris > > > > > Petr Prikryl wrote: > > Hi, > > > > Summary: In my opinion, the C-like prefix > > increment and decrement operators (++i and --i) > > should be marked as "syntax error". > > > > > > Current situation: try... (Python 2.4 (#60, ...)) > > > >>>>i = 1 > >>>>i > > > > 1 > > > >>>>i++ > > > > File "", line 1 > > i++ > > ^ > > SyntaxError: invalid syntax > > > >>>>++i > > > > 1 > > > >>>>--i > > > > 1 > > > > > > Reason for how ++i and --i behaves in Python is > > that it is probably treated as (-(-i)) and (+(+i)) > > respectively. > > > > Rationale: My guess is that many Python users > > do use other languages at the same time. > > The C-family languages do use the prefix increment > > and decrement operators. When used in Python > > no warning appears -- the code simply does not work > > as expected. In the same time, there is probably no > > reason to use the increment and decrement > > prefix operators. On the other hand, the newcommer > > or the programmer that "types ++i automatically > > because of brain synapses say he/she should..." > > is not warned until something does not work. > > > > Con: The situation must be recognized by the parser > > (i.e. someone have to implement it). > > > > Pro: No runtime overhead except of the detection > > of the situation. As Python is a good candidate > > to be used as the language for teaching, the "syntax > > error" would be the pedagogical plus. > > > > Personal experience: Many things in Python work > > intuitively. My C++ experience "forced me" to use > > ++i as described above. I use iteration more these > > days and I know about the ++i problem invisibility > > in Python. But I had to learn by mistake. The ++i > > behaviour is not intuitive for me. > > > > Your opinion? > > > > -- http://mail.python.org/mailman/listinfo/python-list
Replacing lambda() examples... (Re: Lambda going out of fashion)
Hi, I suggest to post here simplified examples that use the lambda to be replaced by non-lambda Pythonic solutions. The ideal result would be the set of rules, how lambdas can be replaced by in future when they become deprecated. Less ideal but valuable may be short examples and counter-examples of using or not using the lambdas. While following the thread "Lambda going out of fashion" I have read cries for not throwing lambdas away and also the opposite opinions. I believe that the theme requires more examples to convince. I personally incline towards the experience of Craig Ringer (see other notices below): "Craig Ringer" wrote in message news:<[EMAIL PROTECTED]>... > [...] > I also make signficant use of Lambda functions, but less than I used to. > I've recently realised that they don't fit too well with Python's > indentation-is-significant syntax, and that in many cases my code is > much more readable through the use of a local def rather than a lambda. > > In other words, I increasingly find that I prefer: > > def myfunction(x): > return x**4 > def mysecondfuntion(x): > return (x * 4 + x**2) / x > make_some_call(myfunction, mysecondfunction) > > to: > > make_some_call( lambda x: x**4, lambda x: (x * 4 + x**2) / x) > > finding the former more readable. The function names are after all just > temporary local bindings of the function object to the name - no big > deal. Both the temporary function and the lambda can be used as > closures, have no impact outside the local function's scope, etc. I'd be > interested to know if there's anything more to it than this (with the > side note that just don't care if my temporary functions are anonymous > or not). > [...] I believe that GvR has a lot of experience and he proved to be very pragmatic. If he thinks that lambdas bring more problems than they solve, it may be some truth in it. I also believe that lamda-trained programmers think a bit differently which does not automatically mean that they think the best way in all cases. Waiting for interesting discussion, Petr -- Petr Prikryl (prikrylp at skil dot cz) --- Odchozí zpráva neobsahuje viry. Zkontrolováno antivirovým systémem AVG (http://www.grisoft.cz). Verze: 6.0.821 / Virová báze: 559 - datum vydání: 21.12. 2004 -- http://mail.python.org/mailman/listinfo/python-list
Re: a question about "return"
"yaru22" wrote in message news:[EMAIL PROTECTED] > In one of the examples in the book I'm reading, it says: > > def __init__(self): > ... > return > > It has nothing after "return". I expected it to have some number like 0 > or 1. What does it mean to have nothing after return? Yes, it has some special value. The value is said to be None. Better to say -- the doc says: "None This type has a single value. There is a single object with this value. This object is accessed through the built-in name None. It is used to signify the absence of a value in many situations, e.g., it is returned from functions that don't explicitly return anything. Its truth value is false. > Why do we even include "return" if we are not putting any value after? If you do not use return in your function, it is the same as if you used return without an argument at the end of the body. It will return None. If you use return, the function returns immediately to the caller. It need not to be the last command. You may want to return earlier. pepr -- http://mail.python.org/mailman/listinfo/python-list
Re: [noob question] References and copying
"zefciu" wrote in message news:[EMAIL PROTECTED] > Where can I find a good explanation when does an interpreter copy the > value, and when does it create the reference. I thought I understand > it, but I have just typed in following commands: > > >>> a=[[1,2],[3,4]] > >>> b=a[1] > >>> b=[5,6] > >>> a > [[1, 2], [3, 4]] > >>> b > [5, 6] > > And I don't understand it. I thought, that b will be a reference to a, > so changing b should change a as well. What do I do wrong. The assignment always copy the reference, never the value. After b=a[1] the b refers to the list object [3,4]. After b=[5,6] the earlier binding is forgotten, the new list with values [5,6] is created and the b is bound to the new list. But if you did b[0] = 5 b[1] = 6 then you would get the expected result. The reason is that b[0] is bound to 3 inside the big list refered by a, and it is rebound to 5. The suggested b[:] = [5, 6] is a shortcut for that (in fact, it is slighly more magical and powerful). > And a second question - can I create a reference to element of a list of > floating points and use this reference to change that element? No. Because the trivial types and also the string type are immutable (i.e. constant). The list would contain references to the constants. You cannot change the value of any constant. You have to replace the reference. Another possibility is to create your own class that will represent one floating point value but will be mutable. In other words, the object of your class will be a container (refered from the list) and its internal state--the floating number--will be changed using the method of the container. pepr -- http://mail.python.org/mailman/listinfo/python-list
Python language extension mechanism for Python 3000... Worth for PEP?
Do you think that the following could became PEP (pre PEP). Please, read it, comment it, reformulate it,... Abstract Introduction of the mechanism for language extensions via modules written using other languages. Extensions of Python could be done via special interpreter extensions. From Python sources, the special modules would look like other modules, with the Python API (the key feature from the Python interpreter's point of view). Inside the special modules, special language features could be implemented and would possibly be interpreted by a different interpreter (the key feature to please those who want to use some special extensions). The goal could be summarized as extension of the idea of writing modules in Python or in C languages. Other kind of modules could be introduced. Then Python would work not only as a glue for modules and utilities, but could also be the glue for different interpreters. Motivation Note: The idea emerged when looking at the video http://video.google.com/videoplay?docid=-6459339159268485356 and when thinking about it. The sequences from it will be referenced like [video 2:10 - 2:30]. I do not want to be the one of the group of the "everybody is the language designer" [video 25:47]. The goal is rather to bypas the problem mentioned in [video 25:35 - 27:50]. There are doubts whether some features should be added to Python 3000 or whether some features are to be removed. The goal is to get rid of the obsolete features but the contradictory goal is not to break the backward compatibility. [video 7:00 - 7:30 - 8:10 - 8:45] There are some group of users of Python with special interests or with some special tastes for programming styles. For example, some users like functional programming (lambda, reduce, map,...). They have expressed so eloquently their wishes that the Python 3000 is not to remove lambda. On the other hand, only the (current) simple form of lambda expressions will remain. [video 41:38 - 43:34] Possibly, the unpleased "functional" people would be pleased if they could write some modules with more powerful lambda that would be interpreted by some special extension of the Python language interpreter. The new, requested special features used only by minority of programmers (but not by the unimportant minority) could be implemented outside the core of the Python interpreter. Rationale To keep the (Python) language clean, it is a good idea to simplify the syntax as much as possible -- if it does not lead to the loss of the power. Some languages are better for some tasks. There will always be people that want to extend the core of the language to support their wishes. The extension of the language via special kinds of modules would not upset the pure Pythonistas and will please "the pure functional-languages followers", for example. There already is something similar available inside the Python interpreter: some modules are implemented in the C language. The key idea is that they offer the same kind of interface that the modules written in Python do. In some sense, Python interpreter is not interested in how the results from the function call are obtained (whether the content of the module must be processed by the Python interpreter or whether the binary code will do it). In some sense, the module written in C can be seen as using "no-interpreter extension". The idea of the module implementation language could be extended (generalized) from "Python or C" to "Python or C or Python-extension". The "Python extension" would be implemented and maintained separately and would not spoil the development of the core. Technically, the goal is to separate the core of the Python language from extensions that will be known in future. In some sense, the mechanism is the adapter to the something else to give it Python interface. The C/C++ would not be the only alternative to implement a module used from a Python script. If modules can be viewed as prefabricated building blocks for writing the Python programs, the interpreter extensions could be viewed as building blocks for the interpreter functionality. As modules, some interpreter extensions could be standard, some could even be considered built-in, some could be from third parties. Some interpreter extensions could be used as a testbed for adding new features: For example, pure UTF-16 sources could be preprocessed by some "experimental" interpreter extension to the form that could be consumed by the core interpreter. And one day, the UTF-8 or 8-bit with explicitly stated encoding can be transformed to the only modern UTF-16 representation that new sources should use. The designers of the core language may freely decide to change the internals if they provide the adapter via the extension.
Q: Cteni unicode retezcu ze souboru UTF-8 s BOM?
Ahoj všeci,
Tak nějak prakticky poprvé se dostávám k tomu,
jak přečíst unicode řetězce ze souboru, který
je uložen ve formátu UTF-8 se signaturou
na začátku (BOM). Nějak se mi nedaří.
Mám takovýto soubor.txt v UTF-8 s BOM
=
První řádek.
Druhý řádek.
Třetí řádek.
Příšerně žluťoučký kůň úpěl ďábelské ódy.
=
... a pustím skript
=
import codecs
f = codecs.open('soubor.txt', 'r', 'utf-8')
for line in f:
print repr(line)
print line[1:]
f.close()
=
Výsledek vypadá takto
=
C:\tmp>python a.py
u'\ufeffPrvn\xed \u0159\xe1dek.\r\n'
První řádek.
u'Druh\xfd \u0159\xe1dek.\r\n'
ruhý řádek.
u'T\u0159et\xed \u0159\xe1dek.\r\n'
řetí řádek.
u'P\u0159\xed\u0161ern\u011b \u017elu\u0165ou\u010dk\xfd k\u016f\u0148
\xfap\u011bl \u010f\xe1belsk\xe9 \xf3dy.\r\n'
říšerně žluťoučký kůň úpěl ďábelské ódy.
=
Všimněte si, že na prvním řádku je \ufeff, což je Byte Order Mark,
který se tam vůbec nemá objevit. Jeví se mi to jako chyba.
Na všech řádcích záměrně nevypisuji printem první znak,
protože u toho prvního řádku to krachne (což je pochopitelné).
Řešil někdo něco podobného? Musí se BOM ukousávat ve vlastní režii?
Díky,
pepr
--
http://mail.python.org/mailman/listinfo/python-list
Sorry (was Re: Cteni unicode retezcu ze souboru UTF-8 s BOM?)
Sorry for the mess, The message should have been sent to the Czech Python mailing list. My fault. pepr "Petr Prikryl" wrote... > Ahoj všeci, > Tak nějak prakticky poprvé se dostávám k tomu, > jak přečíst unicode řetězce ze souboru, který > je uložen ve formátu UTF-8 se signaturou > na začátku (BOM). Nějak se mi nedaří. -- http://mail.python.org/mailman/listinfo/python-list
Re: problem with str()
"Alex Martelli" wrote > Steve Holden wrote: >... > > >> Get yourself a stuffed bear, and next time you have this kind of problem > > >> spend a few minutes explaining to the bear exactly how your program > > >> can't possibly be wrong. Works like a charm. > > > > > > A rubber ducky works much better for that, btw -- more easily washable > > > than a stuffed bear, for example. > > > > > But stuffed bears are so much more knowledgeable about the minutiae of > > software design. > > And yet, the key to Python's strength is duck typing -- if you can teach > the duck to type, you've got it made. ... and then (gradually) rather unrealistic communication dream called "Babylonian fish" can be replaced by slighly more realistic programmers dream called "Python language with natural language processing when programming" (buzzword DuckPython). -- http://mail.python.org/mailman/listinfo/python-list
Re: difference between class and static methods?
"John Salerno" wrote... [...] > So a class method is specifically for using the class name itself as an > object in the method? If that's the case, then it makes some sense now. > I guess the reason I didn't get it before is that this is a feature of > dynamic languages, right? And something that couldn't have been done in > C# anyway? Yes, almost. You can think about a class method as about something that can be called even if no object of that class was created. It can be called through the class name. But it can also be called through the instance (the object). On the other hand, the normal method can be called only through the object. It does not belong to the class -- see below. The class method has access to the class variables, but not to the instance variables (no instance may exists) -- not shown here. Try the following script (I have stored it as a.py) --- class C: def __init__(self): print 'Instance of the class C was created.' @classmethod def myClassMethod(cls): print 'myClassMethod called' def myMethod(self): print 'myMethod (i.e. the normal one) was called.' C.myClassMethod() obj = C() obj.myClassMethod() obj.myMethod() C.myMethod() # cannot be done, error. --- And run it C:\tmp>python a.py myClassMethod called Instance of the class C was created. myClassMethod called myMethod (i.e. the normal one) was called. Traceback (most recent call last): File "a.py", line 18, in ? C.myMethod() TypeError: unbound method myMethod() must be called with C instance as first argument (got nothing instead) pepr -- http://mail.python.org/mailman/listinfo/python-list
Re: BIOCHIP --->>> NO GOOD !!
rainbow.cougar wrote in message > okay wrote: > > To Archbishop Christodoulos Paraskevaides of the Greek Orthodox Church > > in Athens and Greece Archbishop, > > I talked with a Greek Orthodox believer in Australia and he told me two > > I'm thinking a list comprehension... Possibly some filter(map()) for the really orthodox believers... -- http://mail.python.org/mailman/listinfo/python-list
Re: Confused by Python and nested scoping (2.4.3)
I have added some spaces guessing how the original was formatted. See the simplified example and the explanation below... "Sean Givan" wrote... > Hi. I'm new to Python [...] something strange. > This code: > > def outer(): > val = 10 > def inner(): > print val > inner() > outer() > > ..prints out the value '10', which is what I was expecting. > > But this code.. > def outer(): > val = 10 > def inner(): > print val > val = 20 > inner() > print val > outer() > > ..I expected to print '10', then '20', but instead got an error: > >print val > UnboundLocalError: local variable 'val' referenced before assignment. > > I'm thinking this is some bug where the interpreter is getting ahead of > itself, spotting the 'val = 20' line and warning me about something that > doesn't need warning. Or am I doing something wrong? The simplified example of both cases can be script a.py - val = 10 def myFunction(): print val myFunction() - In this case the val is not defined inside myFunction(); therefore, it is searched in the "upper level", above the function body. Such variable is called free variable. script b.py - val = 10 def myFunction(): print val val = 20 myFunction() - In this case the val is assigned inside the myFunction() and it is not marked to be global. In this case Python decides that it will be the local variable (cannot be free variable anymore). Python insists on fact that in one block the variable can be or free or locally bound, but not both. This is decided during the compilation of the module and it does not depend on whether val = 20 assignment precedes the print val command or not. It is decided that it will be local inside myFunction and then the print wants to use the variable that was not assingned yet. pepr P.S. I have just noticed that Terry Jan Reedy answered similarly. Never mind... Repeat, repeat, repeat until you know ;) -- http://mail.python.org/mailman/listinfo/python-list
Re: how to append to a list twice?
"Fredrik Lundh" wrote: > Alex Martelli wrote: > > > > But of course that only does it once, and I don't want to have to copy > > > and paste the append line. Perhaps there's a better way than this. > > > > def makeseries(N): > > series = [N] > > append = series.append > > for tailer in xrange(N-1, -1, -1): > > append(tailer) > > append(tailer) > > But Now You've Violated The DRY Principle!!! Do you mean the "three times -1" in the xrange arguments? :-) pepr -- http://mail.python.org/mailman/listinfo/python-list
Re: A critic of Guido's blog on Python's lambda
"Alex Martelli" wrote... > Joe Marshall wrote: >... > > If you language allows unnamed integers, unnamed strings, unnamed > > characters, unnamed arrays or aggregates, unnamed floats, unnamed > > expressions, unnamed statements, unnamed argument lists, etc. why > > *require* a name for trivial functions? Event the trivial function can have a name. Does it make the trivial function more understandable if I do not give a name? I understand what lambda means, but it is clearer for me to see something like (with more meaningful name than shown here): >>> def fn(x): ... return x + 5 and to use it like... >>> fn(3) 8 Still, I can anonymize it later, if I really need >>> a = [fn] or I can give it another name >>> z = fn In my opinion, the cry for lambda in Python comes from people used to functional languages, because they are not used to the procedural style and it does not fit them at the beginning. Frankly, functional style seems "more strange" to me (i.e. the counter example). Still, I do not say it is bad. But it never came to my mind to say "Please, rewrite the LISP so that it looked more like Pascal. I do not like the lambda." Also, Python is compiled (to bytecode), imperative language, and the form of definition of the chunks of code is more natural to the compiler and to the customs how the procedural program is written and how its parts are referenced and put together to form bigger chunks of code. > I think it's reasonable to make a name a part of functions, classes and > modules because they may often be involved in tracebacks (in case of > uncaught errors): to me, it makes sense to let an error-diagnosing > tracebacks display packages, modules, classes and functions/methods > involved in the chain of calls leading to the point of error _by name_. I agree with Alex here. I USUALLY do not need debugger, but sometimes it is exremely handy to discover what happens (through debugger or few print commands, its a matter of taste). And Python is very fine here: >>> dir(fn) ['__call__', '__class__', '__delattr__', '__dict__', '__doc__', '__get__', '__getattribute__', '__hash__', '__init__', '__module__', '__name__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__str__', 'func_closure', 'func_code', 'func_defaults', 'func_dict', 'func_doc', 'func_globals', 'func_name'] >>> fn.__name__ 'fn' and even the anonymized function still knows its original name and type >>> a[0].__name__ 'fn' >>> type(a[0]) If lambda functions in Python are tweaked internally into normal Python functions... >>> z = lambda x: x * 3 >>> dir(z) ['__call__', '__class__', '__delattr__', '__dict__', '__doc__', '__get__', '__getattribute__', '__hash__', '__init__', '__module__', '__name__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__str__', 'func_closure', 'func_code', 'func_defaults', 'func_dict', 'func_doc', 'func_globals', 'func_name'] >>> z.__name__ '' >>> type(z) ... what makes them better, than the named function? If I do not loose anything by simplification, I want to have it simpler. pepr -- http://mail.python.org/mailman/listinfo/python-list
Re: A critic of Guido's blog on Python's lambda
"Chris Uppal" wrote...
> Alex Martelli wrote:
>
> > I think it's reasonable to make a name a part of functions, classes and
> > modules because they may often be involved in tracebacks (in case of
> > uncaught errors): to me, it makes sense to let an error-diagnosing
> > tracebacks display packages, modules, classes and functions/methods
> > involved in the chain of calls leading to the point of error _by name_.
[...]
> E.g. consider the Smalltalk code (assumed to be the body of a method):
>
> aCollection
> do: [:each |
> each > 0 ifTrue: [^ true]].
> ^ false.
>
> which iterates over a collection checking to see if any element is > 0. If
so
> then the method answers true ("^" -- spelled "return" in Java), otherwise
it
> answers false. In that code,
> [^ true]
> is syntactically and semantically an anonymous function, which is only
invoked
> if the antecedent is true (in point of fact the compiler inlines that
function
> away but I don't think that's relevant here). The passage beginning
> [:each | ...
> and reaching to the matching ] is also an anonymous function with one
parameter
> (each) which is applied to each element of the collection in turn. (In
this
> case it really is an anonymous function, even at the implementation
level.)
> What "name" would you give to either of them ? I don't believe that /any/
name
> is possible, and certainly that no name is desirable.
for element in aCollection:
if element > 0:
return True
return False
And adding "def test(aCollection):" does not make it more complex,
in my opinion. And possibly, the chunk of code may be written
in some other way, more Pythonically. Maybe the attempt to
rewrite programs from other languages into Python and
the effort to use the same "tricks" like in the original program,
causes the cry for preserving lambda in future Python.
pepr
--
http://mail.python.org/mailman/listinfo/python-list
Re: A critic of Guido's blog on Python's lambda
"Chris Uppal" wrote: > Petr Prikryl wrote: > > > for element in aCollection: > > if element > 0: > > return True > > return False > > [I'm not sure whether this is supposed to be an example of some specific > language (Python ?) or just a generic illustration. I'll take it as the > latter, since it makes my point easier to express. I'll also exaggerate, just > a little...] Sorry, I do not know Smalltalk, but this was meant as the transcription of your... | E.g. consider the Smalltalk code (assumed to be the body of a method): | | aCollection | do: [:each | | each > 0 ifTrue: [^ true]]. | ^ false. into Python > But now, in order to hack around the absence of a sensible and useful > feature -- /only/ in order to do so -- you have added two horrible new > complications to your language. You have introduced a special syntax to > express conditionals, and (worse!) a special syntax to express looping. Not > only does that add a huge burden of complexity to the syntax, and semantics, of > the language (and, to a lesser extent, its implementation), but it also throws > out any semblance of uniformity. I guess that it is not me who is confused here. The subject clearly says that the thread is related to Python and to lambda supported by Python. It was only crossposted to other groups and I did not want to remove them -- other people may want to read the thread in the other newsgroups. So, I did not introduced any horible syntax, nor looping construct that would look strange to people used to classical procedural languages. The lambda syntax in Python is the thing that could be viewed as a complication, not the "for" loop or the "if" construction. If you take any English speaking human (even the non-programmer), I could bet that the Python transcription will be more understandable than your Smalltalk example. > E.g. in Java there's an unresolved, and irresolvable, tension between whether a > failing operation should return an error condition or throw an exception [...]. It is more a design problem than the language problem. And it is also the implementation problem (i.e. what is the price of exceptions in comparison with the other code). In Python, the exceptions are intesively used. > E.g. can you add three-way comparisons (less-than, same-as, greater-than to, > say, Python with corresponding three-way conditional control structures to > supplement "if" etc ? Are they on a semantic and syntactic par with the > existing ones ? In Smalltalk that is trivial (too trivial to be particularly > interesting, even), and I presume the same must be true of Lisp (though I > suspect you might be forced to use macros). Such built-in function already is in Python. But you could add it by hand if it were not: def cmp(x, y): if x < y: return -1 if x == y: return 0 return 1 and the "if" supplement (the "switch" or "case" command) could be replaced easily in Python using the hash-table (dictionary) structure. > I should say that if your example /is/ in fact Python, then I believe that > language allows fairly deep hooks into the execution mechanism, so that at > least the "for" bit can be mediated by the collection itself -- which is better > than nothing, but nowhere near what I would call "good". It is a dual point of view. Should the collection be passive data, or not? I believe that the "pure" object oriented view (there are no functions, only the object methods) is not very practical and does not reflect well the big part of the reality that is simulated by programs. Python and C++, for example, allow mixing functions and objects. You should try Python. The "for" construct iterates through a sequence or through all values of the generator, thus making the for loop much more generic than for example in C or other languages. Every language forms the way of thinking. Every language has its strong and weak points. Every language has its followers and haters. Not every language is practical enough to fly around the Earth in the space ship. pepr (Sorry for my broken English.) -- http://mail.python.org/mailman/listinfo/python-list
Does -U option really exist?
"Martin v. Löwis" once (20 Sep 2005) wrote in reply to my question... Simpler transition to PEP 3000 "Unicode only strings"? > As for dropping the u prefix on string literals: > Just try the -U option of the interpreter some time, > which makes all string literals Unicode. If you manage > to get the standard library working this way, you > won't need a per-file decision anymore: just start > your program with 'python -U'. I have failed to find the -U option in Python 2.4.2. Is it something under development? Thanks, pepr -- http://mail.python.org/mailman/listinfo/python-list
python -U problem for 2.4.3c1 on Windows 2000 (was Does -U option really exist?)
I did observe the problem when using the -U
option on Windows 2000. Seems like some infinite
recursion in cp1250.py -- see below.
I did not try it with earlier versions of Python.
Can this be reproduced on your computer?
Thanks for your time and experience,
pepr
P.S. Thanks, Martin, for the hint.
Martin v. Löwis wrote
> Petr Prikryl wrote:
> > Martin v. Löwis wrote
> > > As for dropping the u prefix on string literals:
> > > Just try the -U option of the interpreter some time,
> > > which makes all string literals Unicode. If you manage
> > > to get the standard library working this way, you
> > > won't need a per-file decision anymore: just start
> > > your program with 'python -U'.
>
> > I have failed to find the -U option in Python 2.4.2.
>
[...]
> $ python2.4 -U
> Python 2.4.2 (#2, Sep 30 2005, 21:19:01)
> [GCC 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu8)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
>
> >>> type("")
>
> >>> ^D
[...]
On Windows machine
C:\>python -U
'import site' failed; use -v for traceback
Python 2.4.3c1 (#68, Mar 23 2006, 10:19:27) [MSC v.1310 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> type('')
>>> ^Z
See the 'import site' failure. I do use the sitecustomize.py
(C:\Python24\Lib\site-packages\sitecustomize.py). It contains
-
import sys
sys.setdefaultencoding('cp1250')
-
I did remove the sitecustomize.pyc before the command.
When trying the python -U -v 2>xxx.log, I get the
following (shortened):
# installing zipimport hook
import zipimport # builtin
# installed zipimport hook
# C:\Python24\lib\site.pyc matches C:\Python24\lib\site.py
import site # precompiled from C:\Python24\lib\site.pyc
# C:\Python24\lib\os.pyc matches C:\Python24\lib\os.py
import os # precompiled from C:\Python24\lib\os.pyc
import nt # builtin
# C:\Python24\lib\ntpath.pyc matches C:\Python24\lib\ntpath.py
import ntpath # precompiled from C:\Python24\lib\ntpath.pyc
# C:\Python24\lib\stat.pyc matches C:\Python24\lib\stat.py
import stat # precompiled from C:\Python24\lib\stat.pyc
# C:\Python24\lib\UserDict.pyc matches C:\Python24\lib\UserDict.py
import UserDict # precompiled from C:\Python24\lib\UserDict.pyc
# C:\Python24\lib\copy_reg.pyc matches C:\Python24\lib\copy_reg.py
import copy_reg # precompiled from C:\Python24\lib\copy_reg.pyc
# C:\Python24\lib\types.pyc matches C:\Python24\lib\types.py
import types # precompiled from C:\Python24\lib\types.pyc
# C:\Python24\lib\locale.pyc matches C:\Python24\lib\locale.py
import locale # precompiled from C:\Python24\lib\locale.pyc
import _locale # builtin
# C:\Python24\lib\codecs.pyc matches C:\Python24\lib\codecs.py
import codecs # precompiled from C:\Python24\lib\codecs.pyc
import _codecs # builtin
import encodings # directory C:\Python24\lib\encodings
# C:\Python24\lib\encodings\__init__.pyc matches
C:\Python24\lib\encodings\__init__.py
import encodings # precompiled from C:\Python24\lib\encodings\__init__.pyc
# C:\Python24\lib\encodings\aliases.pyc matches
C:\Python24\lib\encodings\aliases.py
import encodings.aliases # precompiled from
C:\Python24\lib\encodings\aliases.pyc
# C:\Python24\lib\encodings\cp1250.pyc matches
C:\Python24\lib\encodings\cp1250.py
import encodings.cp1250 # precompiled from C:\Python24\lib\encodings\cp1250.pyc
import sitecustomize # from C:\Python24\lib\site-packages\sitecustomize.py
# wrote C:\Python24\lib\site-packages\sitecustomize.pyc
'import site' failed; traceback:
Traceback (most recent call last):
File "C:\Python24\lib\site.py", line 397, in ?
main()
File "C:\Python24\lib\site.py", line 394, in main
if hasattr(sys, "setdefaultencoding"):
File "C:\Python24\lib\encodings\cp1250.py", line 18, in encode
return codecs.charmap_encode(input,errors,encoding_map)
File "C:\Python24\lib\encodings\cp1250.py", line 18, in encode
return codecs.charmap_encode(input,errors,encoding_map)
File "C:\Python24\lib\encodings\cp1250.py", line 18, in encode
return codecs.charmap_encode(input,errors,encoding_map)
[...snip...]
File "C:\Python24\lib\encodings\cp1250.py", line 18, in encode
return codecs.charmap_encode(input,errors,encoding_map)
File "C:\Python24\lib\encodings\cp1250.py", line 18, in encode
return codecs.charmap_encode(input,errors,encoding_map)
RuntimeError: maximum recursion depth exceeded
# C:\Python24\lib\warnings.pyc matches C:\Python24\lib\warnings.py
import warnings # precompiled from C:\Python24\lib\warnings.pyc
# C:\Python24\lib\lineca
Re: Why new Python 2.5 feature "class C()" return old-style class ?
"Aahz" wrote... > Bruno Desthuilliers wrote: > >Aahz a écrit : [...] > >>>Please repeat this 101 times each morning: > >>>"thou shall not use old-style classes for they are deprecated". > >> Classic classes are *NOT* deprecated. > >Perhaps not *officially* yet... > > Not even unofficially. The point at which we have deprecation is when > PEP8 gets changed to say that new-style classes are required for > contributions. My question: Could the old classes be treated in a new Python treated as new classes with "implicit" base object? (I know the Zen... ;-) Example: I use usually a very simple classes. When I add "(object)" to my class definitions, the code continues to works fine -- plus I have new features to use. Why this cannot be done automatically? What could be broken in the old code if it was threated so? Thanks for explanation, pepr -- http://mail.python.org/mailman/listinfo/python-list
