Path-like objects in the standard library
Hallöchen! Path-like objects are accepted by all path-processing functions in the standard library since Python 3.6. Unfortunately, this is not made explicit everywhere. In particular, if I pass a Path in the first argument of subprocess.run, do I use an implementation detail of CPython? Because on https://docs.python.org/3.6/library/subprocess.html, only for the cwd argument the acceptance of Paths is stated explicitly. The same goes for all functions in the shutil module. https://docs.python.org/3.6/library/shutil.html does not mention the path-like protocol anywhere, but the CPython modules seem to accept them anyway. Regards, Torsten. -- Torsten Bronger -- https://mail.python.org/mailman/listinfo/python-list
[issue24132] Direct sub-classing of pathlib.Path
Change by Torsten Bronger <bron...@physik.rwth-aachen.de>: -- nosy: +bronger ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue24132> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
scandir slower than listdir
Hallöchen!
With a 24,000 files directory on an SSD running Ubuntu,
#!/usr/bin/python3
import os, time
start = time.time()
list(os.listdir("/home/bronger/.saves"))
print("listdir:", time.time() - start)
start = time.time()
list(os.scandir("/home/bronger/.saves"))
print("scandir:", time.time() - start)
yields
listdir: 0.045470237731933594
scandir: 0.08043360710144043
However, scandir is supposed to be faster than listdir. Why do I
see this?
Tschö,
Torsten.
--
Torsten Bronger
--
https://mail.python.org/mailman/listinfo/python-list
[issue22005] datetime.__setstate__ fails decoding python2 pickle
Changes by Torsten Bronger <bron...@physik.rwth-aachen.de>: -- nosy: +bronger ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue22005> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22570] Better stdlib support for Path objects
Changes by Torsten Bronger <bron...@physik.rwth-aachen.de>: -- nosy: +bronger ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue22570> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20362] longMessage attribute is ignored in unittest.TestCase.assertRegexpMatches etc
Changes by Torsten Bronger bron...@physik.rwth-aachen.de: -- nosy: +bronger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20362 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
ANN: JuliaBase -- LIMS for specimen-based research published as open source
We are proud to announce that our in-house samples database solution is now published as open source software (AGPL). It is a Python/Django-based framework for creating Web databases for samples. So far, it is used successfully by four in-house departments. For all the details and a demo, visit http://www.juliabase.org. The highlights include: - maximal flexibility for being adapted perfectly to your production and measurement setups, and to your workflows; (that's the reason why it is a programming framework rather than a turnkey application) - keeps track of samples across sample splits - support for pre-evaluating raw data and creating plots - arbitrarily complex searches made easy, e.g. “find all samples with infrared measurements, deposited together with a sample on glass substrate with a conductivity greater than 10^-6 S/cm; oh yes, and only from this year and made by John” - export to spreadsheets - automatic lab notebooks - server interaction with other programs through an HTTP/JSON interface JuliaBase's sources include an example institute that programmers can use as a starting point. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
Hallöchen! Larry Martell writes: On Fri, Jul 18, 2014 at 8:19 AM, Grant Edwards invalid@invalid.invalid wrote: But, I do know that a decent, civilized person just doesn't make insulting comments like that about somebody else's work even if it is true (which I very much doubt). Now, _that's_ funny. This is the internet. If you can't stand the heat get out of the kitchen. Now, _that's_ funny. This is the internet. If you can't stand people who can't stand the heat get out of the kitchen. Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposal: === and !=== operators
Hallöchen! Alan Bawden writes: [...] You lost me right here. If list equality is determined by comparing lists element-by-element, and the second element of old is _not_ equal to the second element of data, then why should old and data be equal? I think Python first tests for identity, and falls back to equality (or the other way round). This behaviour is questionable in my opinion. Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposal: === and !=== operators
Hallöchen! Torsten Bronger writes: Alan Bawden writes: [...] You lost me right here. If list equality is determined by comparing lists element-by-element, and the second element of old is _not_ equal to the second element of data, then why should old and data be equal? I think Python first tests for identity, and falls back to equality (or the other way round). This behaviour is questionable in my opinion. See also https://mail.python.org/pipermail/python-bugs-list/2006-August/035010.html Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.com -- https://mail.python.org/mailman/listinfo/python-list
[issue4470] smtplib SMTP_SSL not working.
Torsten Bronger added the comment: For five Ubuntu releases now, I apply this patch. In contrast to Catalin's statement, it is not solved for me unless the upstream changes of two years ago haven't yet found their way into Ubuntu. I'm currently using Python 2.7.4 on Ubuntu 13.04. That said, the patch solves my issue every time. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4470 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4470] smtplib SMTP_SSL not working.
Torsten Bronger added the comment: Sorry, after having had another look at it, I realised that I have a different SSMTP issue now, non-Python-related. So for me, Ubuntu 13.04 indeed solves my old issue. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4470 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9400] multiprocessing.pool.AsyncResult.get() messes up exceptions
Changes by Torsten Bronger bron...@physik.rwth-aachen.de: -- nosy: +bronger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9400 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4470] smtplib SMTP_SSL not working.
Torsten Bronger bron...@physik.rwth-aachen.de added the comment: No, I don't know how to do that. All I can provide is a minimal version of my code that triggers the above mentioned traceback. It is: import smtplib s = smtplib.SMTP_SSL(relay-auth.rwth-aachen.de) s.login(***, ***) s.sendmail(bron...@physik.rwth-aachen.de, bronger.ran...@googlemail.com], Hello) I hope it helps to understand what I mean. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4470 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4470] smtplib SMTP_SSL not working.
Torsten Bronger bron...@physik.rwth-aachen.de added the comment: Sorry, it must be: import smtplib s = smtplib.SMTP_SSL(relay-auth.rwth-aachen.de) s.login(***, ***) s.sendmail(bron...@physik.rwth-aachen.de, [bronger.ran...@googlemail.com], Hello) (A bracket was missing.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4470 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4470] smtplib SMTP_SSL not working.
Torsten Bronger bron...@physik.rwth-aachen.de added the comment: My Python version is Python 2.7.1+ and the package is called python2.7 2.7.1-5ubuntu2 (Ubuntu Natty). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4470 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4470] smtplib SMTP_SSL not working.
Torsten Bronger bron...@physik.rwth-aachen.de added the comment: I still have to apply Catucci's patch (or a modification of) after every Ubuntu installation or upgrade. Otherwise, I get ... File /usr/lib/python2.7/smtplib.py, line 752, in __init__ SMTP.__init__(self, host, port, local_hostname, timeout) File /usr/lib/python2.7/smtplib.py, line 239, in __init__ (code, msg) = self.connect(host, port) File /usr/lib/python2.7/smtplib.py, line 295, in connect self.sock = self._get_socket(host, port, self.timeout) File /usr/lib/python2.7/smtplib.py, line 757, in _get_socket new_socket = socket.create_connection((host, port), timeout) File /usr/lib/python2.7/socket.py, line 571, in create_connection raise err socket.error: [Errno 111] Connection refused But isn't it that #4066 should have solved the critical part this issue pair 4066/4470? -- nosy: +bronger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4470 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
How to upload a file
Hallöchen! I'm skimming through the various recipies for uploading a file via HTTP. Unfortunately, all of them are awkward but also rather old. (See for example http://stackoverflow.com/questions/68477/send-file-using-post-from-a-python-script) In my module, I do my HTTP request like this: opener = urllib2.build_opener(urllib2.HTTPCookieProcessor(cookielib.CookieJar())) opener.open(url, urllib.urlencode(data, doseq=True)) Well, and now I'd also like to include a file upload to the POST data. The solution should use urllib2, otherwise I'd have to change most of my existing code. If you now say Torsten, unfortunately it *is* so complicated I'll jump through the hoops, but I'd love to hear that with Python 2.6.5 there's an easier way. ;-) Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.com -- http://mail.python.org/mailman/listinfo/python-list
[issue1596321] KeyError at exit after 'import threading' in other thread
Changes by Torsten Bronger bron...@physik.rwth-aachen.de: -- nosy: +bronger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1596321 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2980] Pickle stream for unicode object may contain non-ASCII characters.
Torsten Bronger bron...@physik.rwth-aachen.de added the comment: The problem is the pickle result. It's not about debugging the pickler itself. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2980 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue992389] attribute error after non-from import
Torsten Bronger bron...@physik.rwth-aachen.de added the comment: Maybe it's better to leave it open, waiting for someone to pick it up, even if this is some time in the future? In my opinion, this is suprising behaviour without an actual rationale, and a current implementation feature. I'd be a pitty for me to see it becoming an official part of the language. What bothers me most is that from . import moduleX doesn't work but import package.moduleX does work. So the circular import itself works without problems, however, not with a handy identifier. This is would be an odd asymmetry, I think. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue992389 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: ElementTree: How to return only unicode?
Hallöchen! Stefan Behnel writes: Torsten Bronger wrote: Stefan Behnel writes: Torsten Bronger wrote: [...] My problem is that if there is only ASCII, these methods return ordinary strings instead of unicode. So sometimes I get str, sometimes I get unicode. Can one change this globally so that they only return unicode? [...] I just looked at the code. It seems that you can use your own XMLTreeBuilder subclass and overwrite the ._fixtext() method like this: def _fixtext(self, text): return text Great. Thus, the following monkeypatch seems to do the trick: from xml.etree import ElementTree # FixMe: Must go away with Python 3 ElementTree.XMLTreeBuilder._fixtext = lambda self, text: text Thank you! Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: torsten.bron...@jabber.rwth-aachen.de -- http://mail.python.org/mailman/listinfo/python-list
ElementTree: How to return only unicode?
Hallöchen! I parse an XML file with ElementTree and get the contets with the .attrib, .text, .get etc methods of the tree's nodes. Additionally, I use the find and findtext methods. My problem is that if there is only ASCII, these methods return ordinary strings instead of unicode. So sometimes I get str, sometimes I get unicode. Can one change this globally so that they only return unicode? Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: torsten.bron...@jabber.rwth-aachen.de -- http://mail.python.org/mailman/listinfo/python-list
Re: Style question - defining immutable class data members
Hallöchen! Maxim Khitrov writes: [...] The advantage of doing this is that the assignments are evaluated once and thus the creation of that class is a bit faster. Access is still performed through self.some_value and self.another_value. Is there a reason to prefer the first style over the second? I think that tools like epydoc can generate more accurate API documentation if you write them as instance attributes. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: torsten.bron...@jabber.rwth-aachen.de -- http://mail.python.org/mailman/listinfo/python-list
Re: ElementTree: How to return only unicode?
Hallöchen! Stefan Behnel writes: Torsten Bronger wrote: [...] My problem is that if there is only ASCII, these methods return ordinary strings instead of unicode. So sometimes I get str, sometimes I get unicode. Can one change this globally so that they only return unicode? That's a convenience measure to reduce memory and processing overhead. But is this really worth the inconsistency of having partly str and partly unicode, given that the common origin is unicode XML data? Could you explain why this is a problem for you? I feed ElementTree's output to functions in the unicodedata module. And they want unicode input. While it's not a big deal to write e.g. unicodedata.category(unicode(my_character)), I find this rather wasteful. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: torsten.bron...@jabber.rwth-aachen.de -- http://mail.python.org/mailman/listinfo/python-list
[issue2980] Pickle stream for unicode object may contain non-ASCII characters.
Torsten Bronger bron...@physik.rwth-aachen.de added the comment: I ran into this problem today when writing python data structures into a database. Only ASCII is safe in this situation. I understood the Python docs that protocol 0 was ASCII-only. I use pickle+base64 now, however, this makes debugging more difficult. Anyway, I think that the docs should clearly say that protocol 8 is not ASCII-only because this is important in the Python world. For example, I saw this issue because Django makes an implicit unicode() conversion with my input which fails with non-ASCII. -- nosy: +bronger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2980 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2980] Pickle stream for unicode object may contain non-ASCII characters.
Torsten Bronger bron...@physik.rwth-aachen.de added the comment: protocol 8 -- protocol 0 of course. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2980 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2980] Pickle stream for unicode object may contain non-ASCII characters.
Torsten Bronger bron...@physik.rwth-aachen.de added the comment: Well, Django doesn't story binary data at all but wants you to store image files etc in the file system. Whether this was a good design decision, is beyond the scope of this issue. My points actually are only these: a) the docs strongly suggest that protocol 0 is ASCII-only and this should be clarified (one sentence would be fully sufficient I think) b) currently, there is no way in the standard lib to serialise data in a debuggable, ASCII-only format Probably b) is not important. *I* want to have it currently but this doesn't mean much. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2980 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Attack a sacred Python Cow
Hallöchen! Terry Reedy writes: [...] Or the proposal would have to be that 'self' is mandatory for all programmers in all languages. I think *that* would be pernicious. People are now free to write the more compact 's.sum = s.a + s.b + s.c' if they want instead of the 'self' version. And again, not everyone writes in English. Of course, self would have to become a reserved word. You could say that this may break some code, but I don't see much freedom removed from the language. After all, being a German, I still can't write Für i in range(10). ;-) Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Attack a sacred Python Cow
Hallöchen! Steven D'Aprano writes: On Sat, 26 Jul 2008 11:08:12 +0200, Nikolaus Rath wrote: [...] so 'self' should *automatically* only be inserted in the function declaration, and *manually* be typed for attributes. That idea might have worked many years ago, but not now. The problem is, what happens here? class Foo(object): def foo(self, arg): self.whatever = arg + 1 @classmethod def cfoo(cls, arg): cls.whatever = arg - 1 @staticmethod def sfoo(arg): print arg See news:[EMAIL PROTECTED]. It is only added to non-decorated methods within a class. This implies that you can switch this mechanism off with a noop decorator. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Attack a sacred Python Cow
Hallöchen! D'Arcy J.M. Cain writes: On Sat, 26 Jul 2008 09:45:21 +0200 Torsten Bronger [EMAIL PROTECTED] wrote: Of course, self would have to become a reserved word. You could say that this may break some code, but I don't see much freedom Isn't this a showstopper all by itself? Yes. But I've seen no code that uses some other word. Emacs' syntax highlighting even treats it as reserved. So I think that other counter-arguments are stronger. The in my opinion strongest one is that automatic insertion of self would make Python less verbose but more complicated. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Attack a sacred Python Cow
Hallöchen! D'Arcy J.M. Cain writes: On Sat, 26 Jul 2008 16:25:18 +0200 Torsten Bronger [EMAIL PROTECTED] wrote: Isn't this a showstopper all by itself? Yes. But I've seen no code that uses some other word. Emacs' syntax highlighting even treats it as reserved. So I think that other counter-arguments are stronger. The in my opinion strongest one is that automatic insertion of self would make Python less verbose but more complicated. Well, if we are arguing over which reason to not change it is more important than I would say that we are in violent agreement. :-) Oh, I've never been in favour of the change (news:[EMAIL PROTECTED]). I just don't think that some popular counter-arguments are compelling. ;-) Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Attack a sacred Python Cow
Hallöchen! Kay Schluehr writes: On 26 Jul., 09:45, Torsten Bronger [EMAIL PROTECTED] wrote: Terry Reedy writes: [...] Or the proposal would have to be that 'self' is mandatory for all programmers in all languages. I think *that* would be pernicious. People are now free to write the more compact 's.sum = s.a + s.b + s.c' if they want instead of the 'self' version. And again, not everyone writes in English. Of course, self would have to become a reserved word. ?? This is an extra requirement. Why do you want to make 'self' a keyword? How could one determine which other identifier must be inserted into the method's signature? Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Attack a sacred Python Cow
Hallöchen! Terry Reedy writes: Torsten Bronger wrote: Terry Reedy writes: [...] Or the proposal would have to be that 'self' is mandatory for all programmers in all languages. I think *that* would be pernicious. People are now free to write the more compact 's.sum = s.a + s.b + s.c' if they want instead of the 'self' version. And again, not everyone writes in English. Of course, self would have to become a reserved word. You could say that this may break some code, Will break. No more than Python 3.0 breaks. but I don't see much freedom removed from the language. After all, being a German, I still can't write Für i in range(10). ;-) But you can write 'for ubermenchen in range(10):' and in 3.0, with diacritics added. Would you really feel no loss of freedom if Guido make i0, i1, ... into keywords, which means they could not be used elsewhere, and mandated them as for loop index variables? I would, but I consider self becoming a keyword not even in the same league as i0, i1 etc. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Attack a sacred Python Cow
Hallöchen! Terry Reedy writes: Torsten Bronger wrote: D'Arcy J.M. Cain writes: On Sat, 26 Jul 2008 09:45:21 +0200 Torsten Bronger [EMAIL PROTECTED] wrote: Of course, self would have to become a reserved word. You could say that this may break some code, but I don't see much freedom Isn't this a showstopper all by itself? Yes. But I've seen no code that uses some other word. There is a lot of code you have not seen. Really. In informal code I use 's' and 'o' for 'self' and 'other'. I don't usually post such because it is not considered polite. So you have seen a biased sample of the universe. I didn't say that no code breaks, nor that I've analysed more than 0.1% of the global Python code. But still, this doesn't convice me. I still think that only a very small fraction of Python code would break. Since no one can make a global analysis, it is more sensible to compare it with the amount of code broken by Python 3.0 in my opinion. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Attack a sacred Python Cow
Hallöchen! Bruno Desthuilliers writes: [...] How would you handle this case with an implicit 'self' : class Foo(object): pass def bar(self): print self Foo.bar = bar Just like this. However, the compiler could add self to non-decorated methods which are defined within class. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Attack a sacred Python Cow
Hallöchen! Kay Schluehr writes: On 24 Jul., 11:40, Torsten Bronger [EMAIL PROTECTED] wrote: Bruno Desthuilliers writes: [...] How would you handle this case with an implicit 'self' : class Foo(object): pass def bar(self): print self Foo.bar = bar Just like this. However, the compiler could add self to non-decorated methods which are defined within class. And $self2, $self3, ... to the object methods of nested classes and $cls2, $cls3, ... to the classmethods of those classes...? One could surely find ways to realise this. However, the design goal should be: Make the frequent case simple, and the rare case possible. (Actually, I'm -0 on this anyway because I forget self very seldomly, and you would still have .self all over the place.) Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Attack a sacred Python Cow
Hallöchen! Bruno Desthuilliers writes: Torsten Bronger a écrit : Kay Schluehr writes: On 24 Jul., 11:40, Torsten Bronger [EMAIL PROTECTED] wrote: [...] Just like this. However, the compiler could add self to non-decorated methods which are defined within class. And $self2, $self3, ... to the object methods of nested classes and $cls2, $cls3, ... to the classmethods of those classes...? One could surely find ways to realise this. However, the design goal should be: Make the frequent case simple, and the rare case possible. Given the (more and more prominent) use of decorators, metaclasses and other meta-programming techniques in Python, I'm not sure the cases where you really need access to Python's object model inners are that rare. Not in my code at least. What does not rare mean for you? Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Attack a sacred Python Cow
Hallöchen! Bruno Desthuilliers writes: Torsten Bronger a écrit : Bruno Desthuilliers writes: [...] How would you handle this case with an implicit 'self' : class Foo(object): pass def bar(self): print self Foo.bar = bar Just like this. However, the compiler could add self to non-decorated methods which are defined within class. What's defined within classes are plain functions. It's actually the lookup mechanism that wraps them into methods (and manage to insert the current instance as first argument). And why does this make the implicit insertion of self difficult? I could easily write a preprocessor which does it after all. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Attack a sacred Python Cow
Hallöchen! Sebastian \lunar\ Wiesner writes: Torsten Bronger [EMAIL PROTECTED]: Bruno Desthuilliers writes: Torsten Bronger a écrit : Bruno Desthuilliers writes: [...] Just like this. However, the compiler could add self to non-decorated methods which are defined within class. What's defined within classes are plain functions. It's actually the lookup mechanism that wraps them into methods (and manage to insert the current instance as first argument). And why does this make the implicit insertion of self difficult? I could easily write a preprocessor which does it after all. Who said, that it would be difficult? He just corrected your statement about definitions inside a class, and did not make any assumption about making self implicit. If it is not the implementation, I don't see why the definition inside a class matters at all. It can be realised as a transformation of the syntax tree and would even be transparent for the compiling steps after it. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Amazon: Practical Django Projects by James Bennett (June 2008)
Hallöchen! Bruno Desthuilliers writes: Torsten Bronger a écrit : [EMAIL PROTECTED] writes: On 16 juil, 10:35, Stefan Scholl [EMAIL PROTECTED] wrote: Dave U. Random [EMAIL PROTECTED] wrote: http://snipr.com/PracticalDjango June 2008 is a bit too early. Django isn't ready. Oh, really ? Too bad. But, wait... If Django isn't ready, what's that framework I've been using for almost three years now, then ??? Before writing sarcastic comments, reading the thread would be really polite. You may not have notice, but applied to a piece of software, ready is usually understood as ready for production use. Which Django is, and has been for years now. Yes, so Stefan used the wrong English word. The rest of the thread had already revealed it when you made your statement. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Amazon: Practical Django Projects by James Bennett (June 2008)
Hallöchen! [EMAIL PROTECTED] writes: On 16 juil, 10:35, Stefan Scholl [EMAIL PROTECTED] wrote: Dave U. Random [EMAIL PROTECTED] wrote: http://snipr.com/PracticalDjango June 2008 is a bit too early. Django isn't ready. Oh, really ? Too bad. But, wait... If Django isn't ready, what's that framework I've been using for almost three years now, then ??? Before writing sarcastic comments, reading the thread would be really polite. As far as versioning is concerned, Django's policy is that 1.0 equals API is frozen. And I consider publishing a book four months before the API is polished bad timing, too. Especially because Django is exquisitely documented on its webpage, so there is no urgent need for it. I thought about buying a Django book, too. I'm happy to have delayed it, for the same reason Stefan mentioned. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Cyclic imports
Hallöchen!
James writes:
# a.py
import b
# refer to b.b
# b.py
import a
# refer to a.a
Thanks Dan, but that still doesn't work for me I'm afraid...
I renamed the modules avoid name overloading -- a.py is now:
import b
class A():
print('b.b_mod:', b.b_mod)
Dan's hint is the way to go nevertheless. However, it is still not
possible to actually use the module object on the top-level (i.e.,
while module a.py is read). So, you must delay any access to module
b until everything is fully loaded -- for example, by wrapping the
access in a function which is called from the main program.
On the other hand, the above code was for debugging purposes I
assume. So maybe there's no real problem anyway because all your
uses of module b are wrapped in functions/methods anyway.
Tschö,
Torsten.
--
Torsten Bronger, aquisgrana, europa vetus
Jabber ID: [EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list
Re: Making wxPython a standard module?
Hallöchen! Grant Edwards writes: On 2008-06-14, Torsten Bronger [EMAIL PROTECTED] wrote: [...] IMO, a few of the un-Pythonic things about wxPython are: 1) Window ID numbers. When I started to use wxPython, there was a newly-introduced wx.ID_ANY that you could give instead of -1. My eyes filtered it out after a couple of hours, just as they do with self. Defining a new name for -1 is just painting the wart a different color. We are talking about aesthetics. There, colour matters. ;-) [...] 2) the flags parameter. Well, I like flags, and I don't see that they are unpythonic. I find the code they produce very legible. You're saying that having the user or-together a bunch of bitmasks and pass the result as an integer is a common way for Python functions/object allow the user to turn optional features on and off? Common doesn't matter. Legibility and practicality matter. I even use flags in an own module, although I grew up with Python 2.4. I didn't see a better alternative. The a+ etc things in the built-in open() function certainly are not. [...] [...] 6) Thousands of wx.UPPER_CASE_INTEGER_HEX_CONSTANTS Thank you for the thorough explanations but in my opinion your points are minor. They're minor in that they don't prevent you from writing programs that work, but they're not minor in that they unnecessarily increase the workload of the user without providing any benefit. You can always do it shorter. But I don't think that this is the right approach for a good design. After all, a wxPython with the behaviour you described would not shrink source code by a significant amount. However, I find the resulting source code very much legible. YMMV, but again, this is then not a question of pythonicness. They are sources of bugs. I don't think so. What do you mean? At least, I can only think of bugs that would become obvious during the very first run. (In other words, mere spelling errors.) [...] I rather have the impression that you like terseness, which is totally okay but a different thing. I think that the most common use cases should be handled with a minimum of extra stuff having to be done by the user. It's just not Pythonic to require a user to specify default values for x,y,z when non-default valus for x,y,z are only used in 1 case out of 1. In Python you use named parameters with default values. But wxPython does use keyword arguments and default values, just not in all places you want it to be. [...] I agree that changing the naming conventions and making use of properties would increase pythonicness, but on an already high level. I guess my views on what is pythonic are a lot different. I also don't think it's at all surprising that a C++ library like wxWidgets has an API that isn't very Pythonic. I used to use C++ before I switched to Python, but I don't see any C++ in wxPython. If you don't like certain things, that's okay, but please don't put the label un-pythonic on it because then only very few modules out there are pythonic. (And which ones even depends on the beholder.) Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Making wxPython a standard module?
Hallöchen! Grant Edwards writes: On 2008-06-14, Torsten Bronger [EMAIL PROTECTED] wrote: You're saying that having the user or-together a bunch of bitmasks and pass the result as an integer is a common way for Python functions/object allow the user to turn optional features on and off? Common doesn't matter. Yes it does. Common in Python is what defines Pythonic. Then I have your definition of it. I don't think that it leads to good design, though. In case of doubt, choose what's common in Python, but other characteristics must have higher priority. Legibility and practicality matter. [...] With a little practice and care, functional programming in prefix-notation (a-la Scheme) can both practical and legible, Not legible for a Python-only programmer like me, and I am the target audience. but it still isn't Pythonic. [...] They are sources of bugs. I don't think so. What do you mean? Because certain flags are only to be used in certain contexts, but there's no way to force (or even to indicate) that usage to the user. Related flags are orthogonal so that the library can well detect an error. Okay, you can pass a *very* wrong parameter, like telling wxPython that this event should have an OK button, but I find this problem case artificial. [...] I used to use C++ before I switched to Python, but I don't see any C++ in wxPython. The whole flags thing with a truckload of globally defined integer constants competing for a single namespace is pure C/C++. Were wxWidgets written in Python, I guarantee that wouldn't be the way it was done. Well, of course it would look heavily different with a different history but this applies to every piece of software. As I said, I used flags in my own package, designed with Python 2.4. And I consider myself a purist. So, there are things that are bad or sub-optimal, but flags are a matter of personal preference. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Making wxPython a standard module?
Hallöchen! Grant Edwards writes: On 2008-06-14, Diez B. Roggisch [EMAIL PROTECTED] wrote: And on a personal note: I find it *buttugly*. Do you mind explaining why you find it *buttugly*? [...] For the curious: Not the look feel (albeit I prefer KDE on linux over Gnome, which is a Qt/GTK thing and thus affects wx look feel as well), but the code the designers. I've never used any of the designers, but I agree 100% that wxPython code is nasty ugly. wxPython has a very un-Pythonic API that's is, IMO, difficult to use. I know that such requests may start a never-ending thread but I'd really like to know what you mean with this. I had almost no GUI experience when I started to use wxPython, yet it was a pleasure for me. Really, aesthetics of the source is important to me being a hobby programmer, and I don't like wxPython's camel case and getters and setters. However, even many (if not most) core Python modules don't respect PEP8 or don't use current language features. Besides, passing function names as strings is also a wart, and *I* have simply never understood signal and slots. Maybe we should accept that there is no silver bullet in GUI toolkits, and any personal preferences amongst the Big Four are just a matter of taste. This un-Pythonic thing is arbitrary and unfair wording in my opinion. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Making wxPython a standard module?
Hallöchen! Grant Edwards writes: [...] IMO, a few of the un-Pythonic things about wxPython are: 1) Window ID numbers. When I started to use wxPython, there was a newly-introduced wx.ID_ANY that you could give instead of -1. My eyes filtered it out after a couple of hours, just as they do with self. [...] 2) the flags parameter. Well, I like flags, and I don't see that they are unpythonic. I find the code they produce very legible. [...] 3) the parent/child tree See wx.ID_ANY. [...] 4) sizers Maybe because I come from TeX/LaTeX, i liked sizers immediately. They worked well for me. [...] 5) binding What? you wanted a button that _did_ something when you clicked it? You're right, this can be better. There's too much explicitness. However, if you really hate the construct, you can define a shortcut. [...] 6) Thousands of wx.UPPER_CASE_INTEGER_HEX_CONSTANTS Thank you for the thorough explanations but in my opinion your points are minor. Additionally, most of them are a matter of taste. I don't think that because you didn't find sizers convenient, or some parts too explicit, you can say that wxWidgets is un-Pythonic. I rather have the impression that you like terseness, which is totally okay but a different thing. I agree that changing the naming conventions and making use of properties would increase pythonicness, but on an already high level. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
Hallöchen! Duncan Booth writes: [...] I don't understand your problem: it's just a single thread so killfile or skip it. Although I agree with you that there is no problem, *this* is not a good justification for this thread. One should stay on topic in *every* thread. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: [EMAIL PROTECTED] (See http://ime.webhop.org for further contact info.) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
Hallöchen! Grant Edwards writes: On 2008-05-30, Torsten Bronger [EMAIL PROTECTED] wrote: Duncan Booth writes: [...] I don't understand your problem: it's just a single thread so killfile or skip it. Although I agree with you that there is no problem, *this* is not a good justification for this thread. One should stay on topic in *every* thread. [...] I wouldn't even consider the thread all that OT, but maybe that's just me. Me too, and therefore I see no problem. But one shouldn't break the rules, relying on all others sticking to them. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: [EMAIL PROTECTED] (See http://ime.webhop.org for further contact info.) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python is slow
Hallöchen! cm_gui writes: [...] if python is such a good programming/scripting language, why can't they build a faster interpreter/compiler engine? and beat php and zend. to the python team, rebuild your interpreter! torontolife.com is slow. For me, torontolife.com is exactly as fast as Wikipedia. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: [EMAIL PROTECTED] (See http://ime.webhop.org for further contact info.) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
Hallöchen! Matthew Woodcraft writes: [...] At one time, Guido was very keen on the idea of Python as a language to introduce non-programmers to (under the 'Computer Programming for Everybody' slogan). I think it's rather a shame that this has more-or-less fallen by the wayside. There are lots of people out there producing buggy spreadsheets to do things that would be easier to do in a programming language. I don't think so. It's still reasonably simple to write short Python programs for e.g. the analysis of measurement results. But people simply don't trust cheap non-point'n'click programs which don't occupy two shelves in the bookstore. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: [EMAIL PROTECTED] (See http://ime.webhop.org for further contact info.) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
Hallöchen! Daniel Fetchinson writes: Or just: If command is quit ... Hmmm. In Flaming Thunder, I'm using is (and is an, is a, etc) for assigning and checking types. For example, to read data from a file and check for errors: Read data from input.txt. If data is an error then go to ... Arf ! A goto ! You are surely aware of the fact that the C source of python also uses goto at tons of places. Is that Arf! too? In the hands of a skilled person who really knows what he/she does, it can be a useful statement. But this collides with the goals of FT, which claims to be simple to use. Besides, the above use case for a goto is definitively awful. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: [EMAIL PROTECTED] (See http://ime.webhop.org for further contact info.) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
Hallöchen! Dave Parker writes: [...] Perhaps. Flaming Thunder is only $19.95 per year for an individual (and even less per individual for site licenses), which is less than the cost of just one book on Python. First of all: Although I consider myself part of the Free Software community, I have no problems at all with such a licence model. But ... [...] Plus, me getting paid to work on Flaming Thunder is far more motivating than me not getting paid to work on Python. This weekend, Python users will still be debating how to fix awkwardnesses in the languages (such as FOR loops where you're just counting the loops and not referencing the loop variable) -- but Flaming Thunder users will be getting work done using the REPEAT n TIMES constructs that I'll be implementing. Well, this is besides the point in my opinion. First, what you consider a wart may be loved by someone else. I for example would consider a REPEAT n TIMES feature as Ruby offers it (and soon FT apparently) ugly because it is superfluous. And secondly, *every* language has their warts. So many languages start as clean babies because they offer little and focus on a specific domain. But grown up, they include the same dirty tricks and suprising corners as the big languages. For me being a physicist and a hobby programmer, FT still is a toy language. Cute but titchy. It surely has its applications, but if you produce pocket calculators, don't tell a computer manufacturer that your machines are much simpler to use. Instead, both things simply have their purposes. Python has been around about 15 years, yet still has those awkwardnesses. Flaming Thunder has been out less than 6 months and those awkwardnesses are already getting fixed. The difference: I can't afford to ignore users. Really, the Python developers listen *very* carefully what the users want. Of course, the response time in Python is months rather than days, which has turned out to be a good thing more than once. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: [EMAIL PROTECTED] (See http://ime.webhop.org for further contact info.) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
Hallöchen! Dave Parker writes: Notice that I said free software, not *** FREE *** software 1! (that is, free as in freedom, not free as in beer). Read again my answer, considering this. I misread your meaning. ... twice. Flaming Thunder itself is not free software, is it? Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: [EMAIL PROTECTED] (See http://ime.webhop.org for further contact info.) -- http://mail.python.org/mailman/listinfo/python-list
Re: Am I missing something with Python not having interfaces?
Hallöchen! jmDesktop writes: Studying OOP and noticed that Python does not have Interfaces. Is that correct? Is my schooling for nought on these OOP concepts if I use Python. Am I losing something if I don't use the typical oop constructs found in other languages (Java, C# come to mind.) I'm afraid that if I never use them I'll lose them and when I need them for something beside Python, I'll be lost. Thank you. See also http://www.python.org/dev/peps/pep-3119/ Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: [EMAIL PROTECTED] (See http://ime.webhop.org for further contact info.) -- http://mail.python.org/mailman/listinfo/python-list
Re: #!/usr/bin/env python vs. #!/usr/bin/python
Hallöchen! Gabriel Genellina writes: [...] I can't believe some angry responses in this thread - it's just a technical question, not about which is the best team in the [preferred sports here] National Championship... Well, Python-list is tunnelled to Usenet. Welcome here. ;-) Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: [EMAIL PROTECTED] (See http://ime.webhop.org for further contact info.) -- http://mail.python.org/mailman/listinfo/python-list
Re: Feature suggestion: sum() ought to use a compensated summation algorithm
Hallöchen! Erik Max Francis writes: Szabolcs Horvát wrote: Arnaud Delobelle wrote: sum() works for any sequence of objects with an __add__ method, not just floats! Your algorithm is specific to floats. This occurred to me also, but then I tried sum(['abc', 'efg'], '') and it did not work. Or is this just a special exception to prevent the misuse of sum to join strings? (As I said, I'm only an occasional user.) What you wrote is nonsensical there, no different from 'a' + 1 -- which is why it quite rightly raises a TypeError. No, the above expression should yield ''+'abc'+'efg', look for the signature of sum in the docs. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: [EMAIL PROTECTED] (See http://ime.webhop.org for further contact info.) -- http://mail.python.org/mailman/listinfo/python-list
[issue2504] Add gettext.pgettext() and variants support
Changes by Torsten Bronger [EMAIL PROTECTED]: -- nosy: +bronger __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2504 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: #!/usr/bin/env python vs. #!/usr/bin/python
Hallöchen! D'Arcy J.M. Cain writes: On Fri, 02 May 2008 23:30:01 +1000 Ben Finney [EMAIL PROTECTED] wrote: The OP was asking why people prefer on over the other. My answer is that I prefer specifying give me the default OS Python because anything not installed by the OS is to non-standardised for me to worry about. [...] Certainly #! /usr/bin/python is fine if you never expect your software to run outside of your own little corner of the world but you asked why people prefer the env version and the answer is that we want to write software that runs everywhere that Python runs. Granted, but you must draw the line somewhere anyway. I cannot pollute my program with hundreds of if clauses just to make it work on every quirky system. It's the *systems* where the streamlining must happen, not the programs. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: [EMAIL PROTECTED] (See http://ime.webhop.org for further contact info.) -- http://mail.python.org/mailman/listinfo/python-list
Re: #!/usr/bin/env python vs. #!/usr/bin/python
Hallöchen! D'Arcy J.M. Cain writes: On Fri, 02 May 2008 16:26:51 +0200 Torsten Bronger [EMAIL PROTECTED] wrote: Certainly #! /usr/bin/python is fine if you never expect your software to run outside of your own little corner of the world but you asked why people prefer the env version and the answer is that we want to write software that runs everywhere that Python runs. Granted, but you must draw the line somewhere anyway. I cannot No one is talking about if statements here. Sorry to become laconical, but your reply was so, too: http://en.wikipedia.org/wiki/Abstraction Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: [EMAIL PROTECTED] (See http://ime.webhop.org for further contact info.) -- http://mail.python.org/mailman/listinfo/python-list
Re: relative import broken?
Hallöchen! Sam writes: I didn't look it up myself, but maybe a __init__.py file is missing so that it can be recognised as a package. No, every single one (S, B, and W) has its own __init__.py in u.py Python gives ImportError: No module named S. A silly question: is the directory that contains S in PYTHONPATH or in sys.path? It's in sys.path. S or its parent directory? I added r'C:\Users\Myname\S' to sys.path. Is this the correct usage? Try r'C:\Users\Myname'. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: [EMAIL PROTECTED] (See http://ime.webhop.org for further contact info.) -- http://mail.python.org/mailman/listinfo/python-list
Problems with Cheese Shop
Hallöchen! How can I authorise to the Python Cheese Shop in order to use setup.py upload? Currently, I get Upload failed (401): You must be identified to edit package information Thanks! Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: [EMAIL PROTECTED] (See http://ime.webhop.org for further contact info.) -- http://mail.python.org/mailman/listinfo/python-list
Re: Problems with Cheese Shop
Hallöchen! Christian Heimes writes: Torsten Bronger schrieb: How can I authorise to the Python Cheese Shop in order to use setup.py upload? Currently, I get Upload failed (401): You must be identified to edit package information Try python setup.py register sdist upload I forgot to say that the package itself is already there, just not the current release. Is register still the way to go? Thank you! Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: [EMAIL PROTECTED] (See http://ime.webhop.org for further contact info.) -- http://mail.python.org/mailman/listinfo/python-list
Re: Best way to store config or preferences in a multi-platform way.
Hallöchen! Ivan Illarionov writes: [...] I took the example from http://www.kuro5hin.org/story/2004/10/29/14225/062 I haven't use my own example only because I don't have one at hand right now. YAML, in its simple form, definetely makes me more productive. I wasted too much time with XML in the past and I won't ever use it as a serialization or config/settings format again. .INI/ConfigParser is too limited and has no standards. I just don't see anything better than YAML to do human and Python editable config files and to serialize information for later use. Okay, but serialisation is something completely different. Nobody would use INI files for it. For other things, it simply depends on the use case. For example, I *know* that the configuration files of my pet project will not exceed the dumb section.key=value scheme so anything else would be overkill. Besides, YAML adds another dependency. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: [EMAIL PROTECTED] (See http://ime.webhop.org for further contact info.) -- http://mail.python.org/mailman/listinfo/python-list
Re: Best way to store config or preferences in a multi-platform way.
Hallöchen! Ivan Illarionov writes: [...] For me it looks more like an old-school/new-school thing than use-case thing. I may be wrong, but I see more and more new projects use things like reST and YAML/JSON and it feels like they are gradually replacing traditional old-school solutions. And I've got very strong impression that YAML is a the future of configuration files when Google released their App Engine. In contrast to many other areas of software, configuration files needn't be compatible with anything except the user's brain. So even if the rest of the world uses config format X, you can safely stick with config format Y. I mean, YAML is not really a complex thing, yet it was conceived not before 2001. The reason is that traditional config files do a good job. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: [EMAIL PROTECTED] (See http://ime.webhop.org for further contact info.) -- http://mail.python.org/mailman/listinfo/python-list
Re: Best way to store config or preferences in a multi-platform way.
Hallöchen! Ivan Illarionov writes: On Fri, 02 May 2008 01:21:38 +0200, Torsten Bronger wrote: [...] In contrast to many other areas of software, configuration files needn't be compatible with anything except the user's brain. So even if the rest of the world uses config format X, you can safely stick with config format Y. There are several reasons for compatibility: 1. The user or another developer might want to write GUI front-end to configure your app. With standard format this would be easier. The libraries are there after all -- I don't speak about an own format. [...] 3. Bigger applications that include your sofware as one of its components may need to automate configuration process and update several config files of different smaller apps from one global setting. If you do something complex like this, porting an application to another config format is the smallest problem. Or in other words: This is not something I'd optimise config handling for. That's precisely why first XML and now YAML became popular for config files. I can't speak for YAML, but XML was not used for the config files I have in mind, but as a machine-readable serialisation format for apps settings that you can set in the app itself. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: [EMAIL PROTECTED] (See http://ime.webhop.org for further contact info.) -- http://mail.python.org/mailman/listinfo/python-list
Re: computing with characters
Hallöchen! SL writes: Gabriel Genellina [EMAIL PROTECTED] schreef in bericht news:[EMAIL PROTECTED] En Wed, 30 Apr 2008 04:19:22 -0300, SL [EMAIL PROTECTED] escribió: And that's a very reasonable place to search; I think chr and ord are builtin functions (and not str methods) just by an historical accident. (Or is there any other reason? what's wrong with a.ord() or str.from_ordinal(65))? yes when you know other OO languages you expect this. Anyone know why builtins were chosen? Just curious *Maybe* for aesthetical reasons. I find ord(c) more pleasent for the eye. YMMV. The biggest ugliness though is ,.join(). No idea why this should be better than join(list, separator= ). Besides, ,.join(ux) yields an unicode object. This is confusing (but will probably go away with Python 3). Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: [EMAIL PROTECTED] (See http://ime.webhop.org for further contact info.) -- http://mail.python.org/mailman/listinfo/python-list
Re: computing with characters
Hallöchen! Duncan Booth writes: Torsten Bronger [EMAIL PROTECTED] wrote: The biggest ugliness though is ,.join(). No idea why this should be better than join(list, separator= ). Besides, ,.join(ux) yields an unicode object. This is confusing (but will probably go away with Python 3). It is only ugly because you aren't used to seeing method calls on string literals. I am used to it. Programming very much with unicode, I use .encode and .decode very often and I like them. I consider en/decoding to be an intrinsic feature of strings, but not ord(), which is an external, rather administrative operation on strings (and actually not even this, but on characters) for my taste. However, join() is really bizarre. The list rather than the separator should be the leading actor. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: [EMAIL PROTECTED] (See http://ime.webhop.org for further contact info.) -- http://mail.python.org/mailman/listinfo/python-list
Re: computing with characters
Hallöchen! Marco Mariani writes: Torsten Bronger wrote: However, join() is really bizarre. The list rather than the separator should be the leading actor. No, because join must work with _any sequence_, and there is no sequence type to put the join method on. No, but for the sake of aesthetics (that's what we're talking here after all), it would be better to have it as the first argument in a build-in function. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: [EMAIL PROTECTED] (See http://ime.webhop.org for further contact info.) -- http://mail.python.org/mailman/listinfo/python-list
Re: computing with characters
Hallöchen! Diez B. Roggisch writes: However, join() is really bizarre. The list rather than the separator should be the leading actor. Certainly *not*! This would be the way ruby does it, and IMHO it does not make sense to add join as a string-processing related method/functionality to a general purpose sequence type. Okay, my wording was unfortunate. However, I've already twice (before and after the above posting of mine) said what I mean, namely join(list, separator), possibly with a default value for separator. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: [EMAIL PROTECTED] (See http://ime.webhop.org for further contact info.) -- http://mail.python.org/mailman/listinfo/python-list
Re: relative import broken?
Hallöchen! Sam writes: I also have a problem with relative import; I can't for the life of me figure out how to use the damn thing. I think the main problem is with getting Python to recognize the existence of a package. I have S/ p.py B/ b.py W/ pyw/ u.py ws.py and I'd like to get u.py to import all the other 3 programs. I put empty __init__.py files in all of the above directories (is this necessary?), and even manually added the pathway (r'C:\Myname\S') to sys.path, but when I execute from S import p in u.py Python gives ImportError: No module named S. I didn't look it up myself, but maybe a __init__.py file is missing so that it can be recognised as a package. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: [EMAIL PROTECTED] (See http://ime.webhop.org for further contact info.) -- http://mail.python.org/mailman/listinfo/python-list
Re: relative import broken?
Hallöchen! Sam writes: On Apr 30, 9:11 pm, Hrvoje Niksic [EMAIL PROTECTED] wrote: Sam [EMAIL PROTECTED] writes: I also have a problem with relative import; I can't for the life of me figure out how to use the damn thing. I think the main problem is with getting Python to recognize the existence of a package. I have S/ p.py B/ b.py W/ pyw/ u.py ws.py and I'd like to get u.py to import all the other 3 programs. I put empty __init__.py files in all of the above directories (is this necessary?), and even manually added the pathway (r'C:\Myname\S') to sys.path, but when I execute from S import p in u.py Python gives ImportError: No module named S. A silly question: is the directory that contains S in PYTHONPATH or in sys.path? It's in sys.path. S or its parent directory? Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: [EMAIL PROTECTED] (See http://ime.webhop.org for further contact info.) -- http://mail.python.org/mailman/listinfo/python-list
Re: Simple unicode-safe version of str(exception)?
Hallöchen! Russell E. Owen writes: [...] So...to repeat the original question, is there any simpler unicode-safe replacement for str(exception)? Please show us the tracebacks you get becuae unicode(s) must fail, too, if there are non-ASCII characters involved. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: [EMAIL PROTECTED] (See http://ime.webhop.org for further contact info.) -- http://mail.python.org/mailman/listinfo/python-list
Re: Simple unicode-safe version of str(exception)?
Hallöchen! Russell E. Owen writes: Torsten Bronger [EMAIL PROTECTED] wrote: Russell E. Owen writes: [...] So...to repeat the original question, is there any simpler unicode-safe replacement for str(exception)? Please show us the tracebacks you get becuae unicode(s) must fail, too, if there are non-ASCII characters involved. Why? [...] ,.join([unicode(s) for s in e.args]) u'\xb0' I thought you wanted to have a string. But this is again a unicode. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: [EMAIL PROTECTED] (See http://ime.webhop.org for further contact info.) -- http://mail.python.org/mailman/listinfo/python-list
Re: Simple unicode-safe version of str(exception)?
Hallöchen! Martin v. Löwis writes: Should I report this as a bug? I suspect it's a misfeature. Please no. There isn't much that can be done about it, IMO. One could give Exception a __unicode__ method. On the other hand, this kind of conversion of an exception to something printable is a quite ugly kludge anyway in my opinion, so it needn't special support. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: [EMAIL PROTECTED] (See http://ime.webhop.org for further contact info.) -- http://mail.python.org/mailman/listinfo/python-list
Abuse in comp.lang.python
Path: uni-berlin.de!fu-berlin.de!postnews.google.com!f63g2000hsf.googlegroups.com!not-for-mail Message-ID: [EMAIL PROTECTED] From: [EMAIL PROTECTED] Newsgroups: comp.lang.python Subject: the pink patch Date: Mon, 28 Apr 2008 00:52:20 -0700 (PDT) Lines: 10 Organization: http://groups.google.com NNTP-Posting-Host: 212.241.180.239 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: posting.google.com 1209369140 19824 127.0.0.1 (28 Apr 2008 07:52:20 GMT) X-Complaints-To: [EMAIL PROTECTED] NNTP-Posting-Date: Mon, 28 Apr 2008 07:52:20 + (UTC) Complaints-To: [EMAIL PROTECTED] Injection-Info: f63g2000hsf.googlegroups.com; posting-host=212.241.180.239; posting-account=fGAdLgoAAABaPJnllSky1fhOhiaRCPm2 User-Agent: G2/1.0 X-HTTP-Via: 1.1 ds4204.dedicated.turbodns.co.uk:81 (squid/2.5.STABLE12) X-HTTP-UserAgent: gzip(gfe),gzip(gfe) Xref: wilson.homeunix.com comp.lang.python:23005 the pink patch http://crack.cracksofts.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Python development tools
Hallöchen! Bruno Desthuilliers writes: [...] and it ends multi-line strings at single quotes. it chokes on unbalanced single quotes in triple-single-quoted strings, and on unbalanced double-quotes in triple-double-quoted strings, yes. Given that I never use triple-single-quoted strings (and don't remember having seen such a thing in the thousands of third-part .py files I've read so far), I'd qualify this as at most a very minor annoyance. Not having proper python-shell and pdb integration is more annoying IMHO. My formulation was unfortunate. What doesn't work (at least for me) is something like This is a docstring in which some variables are quoted. Here, variables doesn't seem to belong to the docstring for python-mode. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: [EMAIL PROTECTED] (See http://ime.webhop.org for further contact info.) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python development tools
Hallöchen! [EMAIL PROTECTED] writes: On 23 avr, 19:39, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Are there any completely free developent tools for python scripts like IDLE. I have used IDLE , but I want to try out others also. I saw stuff like PyCrust, but I don't see that it can run the script as well. emacs + python-mode (the one from Python, not the horror that ships with recent emacs versions) What's so bad about it? I just installed python-mode (is this the one with the py- prefixes?), and it ends multi-line strings at single quotes. That's bad. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: [EMAIL PROTECTED] (See http://ime.webhop.org for further contact info.) -- http://mail.python.org/mailman/listinfo/python-list
Re: Is massive spam coming from me on python lists?
Hallöchen! Sjoerd Mullender writes: On 2008-04-21 08:01, Brian Vanderburg II wrote: I've recently gotten more than too many spam messages and all say Sender: [EMAIL PROTECTED] [...] That is just mailman (the mailing list software) keeping track of things. By the way, why does mailman change the Message-IDs when tunneling postings to the newsgroup? This destroys the thread structure. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: [EMAIL PROTECTED] (See http://ime.webhop.org for further contact info.) -- http://mail.python.org/mailman/listinfo/python-list
lost sourcecode: decompyle?
Hallöchen! Due to erroneous use of my VCS, I lost my revision of yesterday. All I have are the pyc v2.5 files. Unfortunately, decompyle can only handle v2.3. Can one convert this, e.g. by de-assembling, manual tweaking, and re-assembling? The result must not be perfect since I still have most content of the files. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: [EMAIL PROTECTED] (See http://ime.webhop.org for further contact info.) -- http://mail.python.org/mailman/listinfo/python-list
Re: Finally had to plonk google gorups.
Hallöchen! NickC writes: Hmm, according to this thread I probably shouldn't bother even trying to contribute to c.l.p discussions that are highlighted in the Python- URL announcements, even in cases where I think a core developer's perspective may be of interest. As someone that only posts here rarely, and uses Google Groups with a Gmail address to do so, it sounds like I'll be kill-filed by a lot of people regardless of the contents of what I post. I don't think that their fraction is significant. Be that as it may, I'm not one of those who accept high amounts of false positives in their anti-spam strategy. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: [EMAIL PROTECTED] (See http://ime.webhop.org for further contact info.) -- http://mail.python.org/mailman/listinfo/python-list
Re: Help needed - I don't understand how Python manages memory
Hallöchen! Gabriel Genellina writes: En Sun, 20 Apr 2008 14:43:17 -0300, Christian Heimes [EMAIL PROTECTED] escribió: Gabriel Genellina schrieb: Apart from what everyone has already said, consider that FreqDist may import other modules, store global state, create other objects... whatever. Pure python code should not have any memory leaks (if there are, it's a bug in the Python interpreter). Not-carefully-written C extensions may introduce memory problems. Pure Python code can cause memory leaks. No, that's not a bug in the interpreter but the fault of the developer. For example code that messes around with stack frames and exception object can cause nasty reference leaks. Ouch! May I assume that code that doesn't use stack frames nor stores references to exception objects/tracebacks is safe? Circular referencing is no leaking on the C level but in a way it is memory leaking, too. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: [EMAIL PROTECTED] (See http://ime.webhop.org for further contact info.) -- http://mail.python.org/mailman/listinfo/python-list
Re: How is GUI programming in Python?
Hallöchen! Joe P. Cool writes: On 12 Apr., 03:34, baalbek [EMAIL PROTECTED] wrote: Delphi/Object Pascal simply sucks big time! I disagree. Delphi/Object Pascal with the VCL (Visual Component Library) is one of the most sophisticated IDEs ever, even better than Qt IMO. [...] I was somewhat disappointed with Delphi. I had used Turbo Pascal 15 years ago, which was one of the best IDEs at that time. It was really good. Now, we use Delphi in our institute for measurement and automation applications with GUI. It is probably possible to work equally well with Delphi, however, none of us have found the right IDE settings for this yet. Especially the behaviour after runtime errors seems to be unpredictable to us, and it is mostly sub-optimal. After having tested most of the dozens of checkboxes I could improve the situation slightly but not more. As far as the GUI composing is concerned, this is great with Delphi, especially for beginners. However, I still prefer the text-only programming in e.g. wxPython (and I'm equally fast with it) but this is a matter of taste. It's like the Word vs LaTeX or Gnuplot vs Origin thing I suppose. All of us were utterly disappointed with the new help system. This used to be a stronghold in Borland products but now, you get explanations à la Method 'foo': do foo with the object. Super. [...] Wrong. It does have a GUI builder - a very good one - and you can do point and click creation of GUIs (nothing wrong with that) but you can also do pure text editor code only programming with it. This shows another disadvantage of such IDEs, namely the editor question. The editor is a very personal piece of software, and I ended up using Emacs for a lot of my Delphi work. I don't consider myself a religious Emacs user -- I was really faster this way. However, this throws away a lot of the IDE's advantages. Thus, having everything in one system is only a good idea if you do Delpi-only. (did anyone mention waste of one's life?), and don't get me started on that primitive, complete utter waste of language called Object Pascal! I'm no big Pascal fan either but Object Pascal has a decent string library and better container literals than C/C++ and Java. The language itself is a matter of taste and I don't waste my time discussing it. Well, there also are objective issues with it that *can* be discussed. You mentioned the string library. This is what caused a lot of headaches here. There is a *lot* of doubled functionality there because there seems to be a transition in Delphi from old to new string functions. The difference between Wide Strings and AnsiStrings is still obscure to me. In .NET Delphi, this seems to have been cleaned up, but I haven't used it. Python/wxPython/Glade == real programmer's toolkit Object Pascal/Delphi == the hobbyist/beginner's toolkit I'm pretty sure that there are more professional software products written in Delphi than in wxPython. Certainly. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: [EMAIL PROTECTED] (See http://ime.webhop.org for further contact info.) -- http://mail.python.org/mailman/listinfo/python-list
Re: Finally had to plonk google gorups.
Hallöchen! Michael Torrie writes: [...] This official python list is one of the few lists that's even still on nntp. All my other ones (gnome, gtk, openldap, clamav, freeradius, etc) are all e-mail mailing lists only and it works very well. In fact, I think it's much better since list subscription can actually be controlled by someone. The admistrative overhead of mailing lists is tedious. Fortunately, most important computer-related lists are on gmane.org. We could list c.l.py there, too. ;-) Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: [EMAIL PROTECTED] (See http://ime.webhop.org for further contact info.) -- http://mail.python.org/mailman/listinfo/python-list
Re: Finally had to plonk google gorups.
Hallöchen! Michael Torrie writes: Torsten Bronger wrote: The admistrative overhead of mailing lists is tedious. Fortunately, most important computer-related lists are on gmane.org. We could list c.l.py there, too. ;-) Running a few lists myself, I don't see this. How is administrative overhead tedious? Most open source projects do it, so I wonder just how tedious it is. Of all the projects I'm associated with in lists, Python is the only one still clinging to NNTP when it appears a normal mail list is just as good. Perish the thought that I ever have to go back to mailing lists again! Finding the web page, entering name and email address and a password, waiting for request for confirmation, sending out confirmation, clicking away welcome message, setting filter in email program, and doing the same for unsubscribing a few days later after having found out that it's not so interesting after all. No. Just going to the group list, search the group, pressing U -- and getting all the postings of the past, too! And for unsubscribing, press U again. No email address, no password, no filters, no hassle. And spam is also very rare in my groups. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: [EMAIL PROTECTED] (See http://ime.webhop.org for further contact info.) -- http://mail.python.org/mailman/listinfo/python-list
Re: Finally had to plonk google gorups.
Hallöchen! Steve Holden writes: Torsten Bronger wrote: [...] The admistrative overhead of mailing lists is tedious. Fortunately, most important computer-related lists are on gmane.org. We could list c.l.py there, too. ;-) c.l.py has been on gmane for years, as comp.python.general (why they have to have their own naming hierarchy i have never understood). Oops, I overlooked this amongst all these interesting groups. ;-) But I don't need it either. Apparently, it also depends on the NNTP server admin team, and I have a very good one (http://www.individual.net/). I also see spam, but not much (7 among the most recent 1000 postings on c.l.py). Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: [EMAIL PROTECTED] (See http://ime.webhop.org for further contact info.) -- http://mail.python.org/mailman/listinfo/python-list
Re: Finally had to plonk google gorups.
Hallöchen! D'Arcy J.M. Cain writes: On Wed, 16 Apr 2008 09:11:09 -0700 Daniel Fetchinson [EMAIL PROTECTED] wrote: Full disclosure: I'm using google groups for both reading and writing. You are? Maybe, but not with this posting. It was sent through the mailing list. By the way, the References: header seems to get lost sometimes through the mailing list when reading it as a Usenet group, so that the discussion trees become a mess. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: [EMAIL PROTECTED] (See http://ime.webhop.org for further contact info.) -- http://mail.python.org/mailman/listinfo/python-list
Re: I just killed GIL!!!
Hallöchen! Tim Daneliuk writes: Daniel Fetchinson wrote: [...] I just had one moment of exceptional clarity, during which realized how I could get the GIL out of my way... It's so simple, I cannot help wondering why nobody has thought of it before. [...] If I were you I would keep it a secret until a Hollywood producer offers big bucks for the film rights. Who would play Guido, I wonder? Ralf Möller. No other. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: [EMAIL PROTECTED] (See http://ime.webhop.org for further contact info.) -- http://mail.python.org/mailman/listinfo/python-list
Re: How is GUI programming in Python?
Hallöchen! [EMAIL PROTECTED] writes: On 11 abr, 20:31, sturlamolden [EMAIL PROTECTED] wrote: [...] I have no experience with GUI programming in Python, but from this discussion it seems if the type of license is not an issue (for FOSS development), PyQt is the best tool because it is: (a) easier to learn and intuitive for programming (this is important to me; I am not that smart...); (b) more stable (although many people have said that wxPython is as stable as any other GUI nowadays; but not more stable (wx) than others); (c) more cross-platform (many people complain that they have to do a lot of things in wxPython for the cross-platform). Is (a) and (c) true or not? If so, how big are these advantages? I really don't know what someone could mean with (c). (b) is probably correct, however for both toolkits this is a not critical from my observation (writing own programs and reading reports of others). (a) is a matter of taste. I, for example, ruled out Qt because I've never understood its mentality. I've read it over and over again, but I didn't grasp it. It depends on your background probably. The great advantage of wxPython seems to be the huge community of users and the large number of widgets/examples/applications available. Unless the Qt people simple can shout much louder, I think both communities are equally sized, but I don't know for sure. Reformulating my question: Which GUI tool, wxPython or PyQt, is more pythonic? In my opinion: none. This was important to me, too, so I looked at it closely when I chose my GUI toolkit. wxPython is traditionally considered unpythonic which is a bit unfair now. They tweaked it a little in recent years and it is reasonable pythonic now. It still has its warts, but Qt definitely has them, too. If you want to have it clean, you must climb up to another level of abstraction (Dabo, Wax etc). I wouldn't do this because it gets slower and less well supported by a large community. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: [EMAIL PROTECTED] (See http://ime.webhop.org for further contact info.) -- http://mail.python.org/mailman/listinfo/python-list
[issue992389] attribute error after non-from import
Torsten Bronger [EMAIL PROTECTED] added the comment: I dare to make a follow-up although I have no idea at all about the internal processes in the Python interpreter. But I've experimented with circular imports a lot recently. Just two points: First, I think that circular imports don't necessarily exhibit a sub-opimal programming style. I had a large parser module which I just wanted to split in order to get handy file sizes. However, the parser parses human documents, and layout element A defined in module A may contain element B from module B and vice versa. In a language with declarations, you just include a big header file but in Python, you end up with circular imports. Or, you must stay with large files. So, while I think that this clean error message Nick suggests is a good provisional solution, it should not make the impression that the circular import is a flaw by itself. And secondly, the problem with modules that are not yet populated with objects is how circular imports have worked in Python anyway. You can easily cope with it by not referencing the imported module's objects in the top-level code of the importing module (but only in functions and methods). Tracker [EMAIL PROTECTED] http://bugs.python.org/issue992389 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
unittest: which directory structure?
Hallöchen! I try to port my doctests to unittest. I've found good turorials about *writing* unit tests but not about organising the files. What's the best way to arrange the test source files? I made a directory called tests on the same level as my package, with (roughly) one test module per package module and wanted to call each of them from my Makefile or from some sort of root test module. However, I cannot easily import the to-be-tested module. Currently, I begin every test module with # append the local package path to sys.path import sys, os.path rootpath = os.path.split(os.path.dirname(os.path.abspath(__file__)))[0] sys.path.append(rootpath) in order to be able to import the source modules. I surely have missed something because this is only a workaround solution. Thanks for any hints! Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: [EMAIL PROTECTED] (See http://ime.webhop.org for further contact info.) -- http://mail.python.org/mailman/listinfo/python-list
Re: How is GUI programming in Python?
Hallöchen! Michel Bouwmans writes: Gabriel Genellina wrote: Michel Bouwmans [EMAIL PROTECTED] escribió: Gabriel Genellina wrote: Another annoying thing with the Qt license is that you have to choose it at the very start of the project. You cannot develop something using the open source license and later decide to switch to the commercial licence and buy it. Unless you're a company with a risk of being checked for legal software etc., you can always ignore that allthough not very legal. I just ignore Qt itself. Then you're ignorant. What do you prefer than? Well ... don't expect answers that you like when you suggest doing something which is not allowed. [...] - WxPython is terribly unstable. I can't confirm that. When I chose wxPython after thorough consideration one year ago, my impression was that reports of instability were indeed frequent but rather old. Apparently, the situation had improved. Does your experience rely on recent use? Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: [EMAIL PROTECTED] (See http://ime.webhop.org for further contact info.) -- http://mail.python.org/mailman/listinfo/python-list
Cyclic relative imports don't work
Hallöchen! Assume the follwing package structure: main.py package/ __init__.py [empty] moduleX.py moduleY.py main.py says: from package import moduleX moduleX.py says: from . import moduleY and moduleY.py says: from . import moduleX However, this doesn't work: [EMAIL PROTECTED]:~/temp/packages-test$ python main.py Traceback (most recent call last): File main.py, line 1, in module from package import moduleX File /home/bronger/temp/packages-test/package/moduleX.py, line 1, in module from . import moduleY File /home/bronger/temp/packages-test/package/moduleY.py, line 1, in module from . import moduleX ImportError: cannot import name moduleX If I turn the relative imports to absolute ones, it works. But I'd prefer the relative notation for intra-package imports. Why is this restriction? Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: [EMAIL PROTECTED] (See http://ime.webhop.org for further contact info.) -- http://mail.python.org/mailman/listinfo/python-list
Re: Coping with cyclic imports
Hallöchen! Jeffrey Froman writes: [...] Cyclic imports are not a problem by themselves, but cyclic definitions are. Thus: # a.py import b x = 1 # b.py import a x = 2 works fine, but: # a.py import b x = 1 # b.py import a x = a.x + 1 # circular definition does not. Okay, thanks, but after some own investigations, I think that the clever bit is somewhere else. The above works if you call a.py as the main program, because then a.py is not yet loaded as such when import a is executed. So a.py gets executed twice, once by import a, and once after the whole import thing as the main program. Actually, there seems to be only one case that is dangerous: If you import a module cyclicly, it may be that you only get its name imported but this name points to a yet empty module. Then, you must not refer to things in it while the current module itself is executed. But you may well refer to things in it from functions or methods, because they are called much later, when the whole bunch of modules is already completely loaded and populated. Consequently, from a import x also fails if a is incomplete. So, the last question is: Under which circumstances does this happen? It happens when you import a module which imports (directly or indictly) the current module and which comes before the current module in the import order while the program runs. If you don't rely on imported things at top-level code (but only in functions and methods which in turn must not be called from the top-level), everything is fine. Can anybody confirm that this is correct? Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: [EMAIL PROTECTED] (See http://ime.webhop.org for further contact info.) -- http://mail.python.org/mailman/listinfo/python-list
Re: Translating keywords
Hallöchen! Gabriel Genellina writes: [...] Python 3 allows for unicode identifiers, but I don'k know any plans for using unicode keywords too. Looks funny: ∀ x ∈ values: if x ∉ forbidden ∧ x ≠ y: print(x, Γ(x), √(x)) print(∑(values)) near = λ a,b,ε=0.01: a-ε ≤ b ≤ a+ε As far as I've understood it, only letters are allowed in identifiers rather than arbitrary Unicode code points. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: [EMAIL PROTECTED] (See http://ime.webhop.org for further contact info.) -- http://mail.python.org/mailman/listinfo/python-list
Coping with cyclic imports
Hallöchen! I have a rather fat module that represents a document parser -- inline elements, block elements, and the like. Now I want to split it into many modules to make everything more manageable. But at the moment I don't see how to avoid cyclic imports: A document element A, which is represented my module parser.A, may contain the element B, as defined in parser.B. And vice versa. So both modules must import each other, as far as I can see. I know that cyclic imports work in Python under certain circumstances. Can anyone refer me to a page which explains *when* this works? Because at least once, the imported module was not finished and thus largely unusual. Thank you! Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: [EMAIL PROTECTED] (See http://ime.webhop.org for further contact info.) -- http://mail.python.org/mailman/listinfo/python-list
Re: Is there any way to say ignore case with in?
Hallöchen! [EMAIL PROTECTED] writes: Is there any way in python to say if string1 in string2: do something ignoring the case of string1 and string2? You can normalise both first, i.e. converting to lower case. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: [EMAIL PROTECTED] (See http://ime.webhop.org for further contact info.) -- http://mail.python.org/mailman/listinfo/python-list
Re: Why prefer != over for Python 3.0?
Hallöchen! Jorge Vargas writes: On Tue, Apr 1, 2008 at 6:03 AM, Gabriel Genellina [EMAIL PROTECTED] wrote: [...] I think it should be easy to add support for ≠≤≥ and even λ, only the tokenizer has to be changed. show me a keyboard that has those symbols and I'm all up for it. For = I have to press three buttons, for ≤ I have to press four buttons. Not much of a difference. ;-) However, I'm slightly disappointed with the UTF-8 support in some mail clients involved in this thread, so Unicode surely has not arrived yet. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: [EMAIL PROTECTED] (See http://ime.webhop.org for further contact info.) -- http://mail.python.org/mailman/listinfo/python-list
Re: Why prefer != over for Python 3.0?
Hallöchen! Bjoern Schliessmann writes: Torsten Bronger wrote: Emacs is generally not regarded as being convenient, however, it has very strong input methods. I type \gtrless and get ?, or \forall and get ?. Doesn't KNode support UTF-8? I wonder where the point of this is. :) Why use fancy unicode chars if they're not better to read (apart from not being readable with every font) and require at least the same amount of keypresses? Who wants to minimize the number of keypresses? We're not Perl after all. ;-) As a general rule of thumb in typography, more glyph forms increase readability. APL is not readable at all but this is due to its syntax I suppose. I find hdante's excerpt very readable. The only reason why we don't use those special characters is that they aren't ASCII. While ∀ or ∈ are questionable because Python prefers English words instead of scientific symbols, ≠ or ≤ would be certainly more legible than != or =. But they are not ASCII, so there is no net benefit. However, I'm quite sure that when Unicode has arrived almost everywhere, some languages will start considering such characters in their core syntax. Python 3.0 allows for Unicode letters in identifiers, and there's still room for improvement. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: [EMAIL PROTECTED] (See http://ime.webhop.org for further contact info.) -- http://mail.python.org/mailman/listinfo/python-list
Re: Why prefer != over for Python 3.0?
Hallöchen! Bjoern Schliessmann writes: Lie wrote: Ah yes, that is also used (I completely forgot about that one, my math's aren't that sharp anymore) and I think it's used more frequently than . Where did you read that (I mean, which country)? I've never seen this sign in any german or english book on mathematics/physics/engineering I saw. Maybe he means ≷. but my argument was that no math book use != or (except in math for programmers). That's true. Personally, I don't ever use a!=b in favor of not a==b. As a side note, I've always found == rather ugly. I'd prefer to have = for both purposes. The constructs that wouldn't work anymore are rare as far as I can see (and possibly there are even workarounds). Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: [EMAIL PROTECTED] (See http://ime.webhop.org for further contact info.) -- http://mail.python.org/mailman/listinfo/python-list
