[issue46598] ElementTree: wrong XML prolog for the utf-8-sig encoding
New submission from Petr Prikryl :
When ElementTree object is to be written to the file, and when BOM is needed,
the 'utf-8-sig' can be used for the purpose. However, the XML prolog then looks
like...
... and that encoding in the prolog makes no sense. Therefore,
the utf-8-sig is changed to utf-8 for the purpose.
To fix the situation, the following two lines should be added to
`cpython/Lib/xml/etree/ElementTree.py`
`elif enc_lower == "utf-8-sig":
declared_encoding = "utf-8"
`
just above the line 741 that says
`write("\n" % (
declared_encoding,))`
I have already cloned the main branch, added the lines to
`https://github.com/pepr/cpython.git`, and sent pull request.
I have tested the functionality locally with `Python 3.10.2
(tags/v3.10.2:a58ebcc, Jan 17 2022, 14:12:15) [MSC v.1929 64 bit (AMD64)] on
win32`
--
components: Library (Lib)
messages: 412247
nosy: prikryl
priority: normal
pull_requests: 29231
severity: normal
status: open
title: ElementTree: wrong XML prolog for the utf-8-sig encoding
versions: Python 3.10
___
Python tracker
<https://bugs.python.org/issue46598>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16322] time.tzname on Python 3.3.0 for Windows is decoded by wrong encoding
Petr Prikryl added the comment:
@eryksun: I see. In my case, I can set the locale before importing the time
module. However, the code (asciidoc3.py) will be used as a module, and I cannot
know if the user imported the time module or not.
Instead of your suggestion
result = result.encode('latin-1').decode('mbcs')
I was thinking to create a module say wordaround16322.py like this:
---
import locale
locale.setlocale(locale.LC_ALL, '')
import importlib
import time
importlib.reload(time)
---
I thought that reloading the time module would be the same as importing is
later, after setting locale. If that worked, the module could be simply
imported wherever it was needed. However, it does not work when imported after
importing time. What is the reason? Does reload() work
only for modules coded as Python sources? Is there any other approach that
would implement the workaroundXXX.py module?
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue16322>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16322] time.tzname on Python 3.3.0 for Windows is decoded by wrong encoding
Petr Prikryl added the comment:
I have worked around a bit differently -- the snippet from the code:
result = time.tzname[0]# simplified version of the original code.
# Because of the bug in Windows libraries, Python 3.3 tried to work around
# some issues. However, the shit hit the fan, and the bug bubbled here.
# The `time.tzname` elements are (unicode) strings; however, they were
# filled with bad content. See https://bugs.python.org/issue16322 for
details.
# Actually, wrong characters were passed instead of the good ones.
# This code should be skipped later by versions of Python that will fix
# the issue.
import platform
if platform.system() == 'Windows':
# The concrete example for Czech locale:
# - cp1250 (windows-1250) is used as native encoding
# - the time.tzname[0] should start with 'Střední Evropa'
# - the ascii('Střední Evropa') should return "'St\u0159edn\xed Evropa'"
# - because of the bug it returns "'St\xf8edn\xed Evropa'"
#
# The 'ř' character has unicode code point `\u0159` (that is hex)
# and the `\xF8` code in cp1250. The `\xF8` was wrongly used
# as a Unicode code point `\u00F8` -- this is for the Unicode
# character 'ø' that is observed in the string.
#
# To fix it, the `result` string must be reinterpreted with a different
# encoding. When working with Python 3 strings, it can probably
# done only through the string representation and `eval()`. Here
# the `eval()` is not very dangerous because the string was obtained
# from the OS library, and the values are limited to certain subset.
#
# The `ascii()` literal is prefixed by `binary` type prefix character,
# `eval`uated, and the binary result is decoded to the correct string.
local_encoding = locale.getdefaultlocale()[1]
b = eval('b' + ascii(result))
result = b.decode(local_encoding)
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue16322>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16322] time.tzname on Python 3.3.0 for Windows is decoded by wrong encoding
Petr Prikryl added the comment:
I have just observed behaviour for the Czech locale. I tried to avoid
collisions with stdout encoding, writing the strings into a file using UTF-8
encoding:
tzname_bug.py
--
#!python3
import time
import sys
with open('tzname_bug.txt', 'w', encoding='utf-8') as f:
f.write(sys.version + '\n')
f.write('Should be: Střední Evropa (běžný čas) | Střední Evropa (letní
čas)\n')
f.write('but it is: ' + time.tzname[0] + ' | ' + time.tzname[1] + '\n')
f.write('types: ' + repr(type(time.tzname[0])) + ' | ' +
repr(type(time.tzname[1])) + '\n')
f.write('Should be as ascii: ' + ascii('Střední Evropa (běžný čas) |
Střední Evropa (letní čas)') + '\n')
f.write('but it is as ascii: ' + ascii(time.tzname[0]) + ' | ' +
ascii(time.tzname[1]) + '\n')
---
It creates the tzname_bug.txt with the content (copy/pasted from
UNICODE-capable editor (Notepad++, the indicator at the right bottom corner
shows UTF-8.
---
3.5.0 (v3.5.0:374f501f4567, Sep 13 2015, 02:27:37) [MSC v.1900 64 bit (AMD64)]
Should be: Střední Evropa (běžný čas) | Střední Evropa (letní čas)
but it is: Støední Evropa (bìný èas) | Støední Evropa (letní èas)
types: |
Should be as ascii: 'St\u0159edn\xed Evropa (b\u011b\u017en\xfd \u010das) |
St\u0159edn\xed Evropa (letn\xed \u010das)'
but it is as ascii: 'St\xf8edn\xed Evropa (b\xec\x9en\xfd \xe8as)' |
'St\xf8edn\xed Evropa (letn\xed \xe8as)'
---
--
nosy: +prikryl
Added file: http://bugs.python.org/file40507/tzname_bug.py
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue16322>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1145257] shutil.copystat() may fail...
Petr Prikryl added the comment: Well, it is quite an old event. Anyway, I have fixed the simple example, and launched it on Python 2.6, 2.7, 3.2, 3.3. It does not fail now. But I did not tested it heavily. From my point of view, it was probably fixed. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1145257 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
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
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:\tmppython 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
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. Another
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
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
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]) type 'function' 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__ 'lambda' type(z) type 'function' ... 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: 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: 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: 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:\tmppython 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: 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
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()
type 'unicode'
^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('')
type 'unicode'
^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 2xxx.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\linecache.pyc matches C:\Python24\lib\linecache.py
import linecache # precompiled from C:\Python24\lib\linecache.pyc
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.
# clear __builtin__._
# clear sys.path
# clear sys.argv
# clear sys.ps1
# clear sys.ps2
# clear sys.exitfunc
# clear sys.exc_type
# clear sys.exc_value
# clear
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
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
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:\binpython glurp.py abcß* 'abc\xdf\x95' u'abc\xdf\u2022' Neil -- 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 Mills 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
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
attachment: test.png--
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 zprva neobsahuje viry. Zkontrolovno antivirovm systmem AVG (http://www.grisoft.cz). Verze: 6.0.821 / Virov bze: 559 - datum vydn: 21.12. 2004 -- 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 stdin, 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 stdin, 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
