Re: [Python-Dev] GIL musings (was Re: Thoughts fresh after EuroPython)

2010-07-29 Thread Maciej Fijalkowski
On Thu, Jul 29, 2010 at 6:53 AM, Greg Ewing wrote: > On 28/07/10 23:12, Antoine Pitrou wrote: > >> It should be noted, though, that a full GC can be detrimental to >> real-time applications. Kristján has already explained how some of his >> software disabled the cyclic GC, and took care of breakin

Re: [Python-Dev] Best practice for new namespace (from C/API)

2010-07-29 Thread Oleg Broytman
Hello. We are sorry but we cannot help you. This mailing list is to work on developing Python (adding new features to Python itself and fixing bugs); if you're having problems learning, understanding or using Python, please find another forum. Probably python-list/comp.lang.python mailing list/

Re: [Python-Dev] Thoughts fresh after EuroPython

2010-07-29 Thread Nick Coghlan
On Thu, Jul 29, 2010 at 8:57 AM, Jesse Noller wrote: > I thought at the last two pycons, we've all discussed that we should > have a system in place for marking tests *and* modules within the > stdlib as "will only work on FooPython". I suspect that it's waiting > on the shared-stdlib effort, whic

Re: [Python-Dev] Best practice for new namespace (from C/API)

2010-07-29 Thread Nick Coghlan
On Thu, Jul 29, 2010 at 8:23 PM, Oleg Broytman wrote: > Hello. > >   We are sorry but we cannot help you. This mailing list is to work on > developing Python (adding new features to Python itself and fixing bugs); > if you're having problems learning, understanding or using Python, please > find a

Re: [Python-Dev] Thoughts fresh after EuroPython

2010-07-29 Thread Jesse Noller
On Thu, Jul 29, 2010 at 8:10 AM, Nick Coghlan wrote: > On Thu, Jul 29, 2010 at 8:57 AM, Jesse Noller wrote: >> I thought at the last two pycons, we've all discussed that we should >> have a system in place for marking tests *and* modules within the >> stdlib as "will only work on FooPython". I su

[Python-Dev] unexpected import behaviour

2010-07-29 Thread Daniel Waterworth
Hi, I'm not sure if this is a bug or not, I certainly didn't expect it. If you create a file called test.py with the following contents, class Test: pass def test_1(): import test print Test == test.Test if __name__ == '__main__': test_1() and then run it ($ python test.py), it

Re: [Python-Dev] unexpected import behaviour

2010-07-29 Thread Oleg Broytman
Hello. We are sorry but we cannot help you. This mailing list is to work on developing Python (adding new features to Python itself and fixing bugs); if you're having problems learning, understanding or using Python, please find another forum. Probably python-list/comp.lang.python mailing list/

Re: [Python-Dev] unexpected import behaviour

2010-07-29 Thread Nick Coghlan
On Thu, Jul 29, 2010 at 4:32 PM, Daniel Waterworth wrote: > Hi, > > I'm not sure if this is a bug or not, I certainly didn't expect it. If > you create a file called test.py with the following contents, > > class Test: >    pass > > def test_1(): >    import test >    print Test == test.Test > > i

Re: [Python-Dev] unexpected import behaviour

2010-07-29 Thread Michael Foord
On 29/07/2010 07:32, Daniel Waterworth wrote: Hi, I'm not sure if this is a bug or not, I certainly didn't expect it. If you create a file called test.py with the following contents, The issue is that when your code is executed as a script it is run as the __main__ module and not as the t

[Python-Dev] [Concurrency / parallelism] Re: Thoughts fresh after EuroPython

2010-07-29 Thread Sarah Mount
On 25 July 2010 19:26, Jesse Noller wrote: > On Sat, Jul 24, 2010 at 10:08 AM, Guido van Rossum wrote: >> - Concurrency and parallelism: Russel Winder and Sarah Mount pushed >> the idea of CSP >> (http://en.wikipedia.org/wiki/Communicating_sequential_processes) in >> several talks at the confere

[Python-Dev] Proposal: make float.__str__ identical to float__repr__ in Python 3.2

2010-07-29 Thread Mark Dickinson
Now that we've got the short float repr in Python, there's less value in having float.__str__ truncate to 12 significant digits (as it currently does). For Python 3.2, I propose making float.__str__ use the same algorithm as float.__repr__ for its output (and similarly for complex). Apart from si

Re: [Python-Dev] Proposal: make float.__str__ identical to float__repr__ in Python 3.2

2010-07-29 Thread Michael Foord
On 29/07/2010 19:47, Mark Dickinson wrote: Now that we've got the short float repr in Python, there's less value in having float.__str__ truncate to 12 significant digits (as it currently does). For Python 3.2, I propose making float.__str__ use the same algorithm as float.__repr__ for its outpu

Re: [Python-Dev] Proposal: make float.__str__ identical to float__repr__ in Python 3.2

2010-07-29 Thread Łukasz Langa
Wiadomość napisana przez Mark Dickinson w dniu 2010-07-29, o godz. 20:47: > Now that we've got the short float repr in Python, there's less value > in having float.__str__ truncate to 12 significant digits (as it > currently does). For Python 3.2, I propose making float.__str__ use > the same al

Re: [Python-Dev] Proposal: make float.__str__ identical to float__repr__ in Python 3.2

2010-07-29 Thread Raymond Hettinger
On Jul 29, 2010, at 11:47 AM, Mark Dickinson wrote: > Now that we've got the short float repr in Python, there's less value > in having float.__str__ truncate to 12 significant digits (as it > currently does). For Python 3.2, I propose making float.__str__ use > the same algorithm as float.__rep

Re: [Python-Dev] Proposal: make float.__str__ identical to float__repr__ in Python 3.2

2010-07-29 Thread Mark Dickinson
On Thu, Jul 29, 2010 at 8:16 PM, Raymond Hettinger wrote: > > On Jul 29, 2010, at 11:47 AM, Mark Dickinson wrote: > >> Now that we've got the short float repr in Python, there's less value >> in having float.__str__ truncate to 12 significant digits (as it >> currently does).  For Python 3.2, I pr

Re: [Python-Dev] Proposal: make float.__str__ identical to float__repr__ in Python 3.2

2010-07-29 Thread Guido van Rossum
On Thu, Jul 29, 2010 at 1:30 PM, Mark Dickinson wrote: > On Thu, Jul 29, 2010 at 8:16 PM, Raymond Hettinger > wrote: >> >> On Jul 29, 2010, at 11:47 AM, Mark Dickinson wrote: >> >>> Now that we've got the short float repr in Python, there's less value >>> in having float.__str__ truncate to 12 si

Re: [Python-Dev] [isssue 2001] Pydoc enhancement patch questions

2010-07-29 Thread Ron Adam
FWIW, I am +1 on dropping tkinter interface. Tkinter window looks foreign next to browser and server-side GUI that opens a new client window with each search topic does not strike me as most usable design. Furthermore, I just tried to use it on my OSX laptop and it crashed after I searched fo

Re: [Python-Dev] Proposal: make float.__str__ identical to float__repr__ in Python 3.2

2010-07-29 Thread Terry Reedy
On 7/29/2010 4:30 PM, Mark Dickinson wrote: As you say, it's just one less surprise, and one less thing to explain: a small shrinkage of the mental footprint of the language. With this change, I believe the only difference between str(ob) and repr(ob) will be the addition of quotes. If so, p

Re: [Python-Dev] Proposal: make float.__str__ identical tofloat__repr__ in Python 3.2

2010-07-29 Thread Robert Brewer
Mark Dickinson wrote: > Now that we've got the short float repr in Python, there's less value > in having float.__str__ truncate to 12 significant digits (as it > currently does). For Python 3.2, I propose making float.__str__ use > the same algorithm as float.__repr__ for its output (and similarl

Re: [Python-Dev] Proposal: make float.__str__ identical tofloat__repr__ in Python 3.2

2010-07-29 Thread Michael Foord
On 29/07/2010 22:37, Robert Brewer wrote: Mark Dickinson wrote: Now that we've got the short float repr in Python, there's less value in having float.__str__ truncate to 12 significant digits (as it currently does). For Python 3.2, I propose making float.__str__ use the same algorithm as fl

Re: [Python-Dev] Proposal: make float.__str__ identical to float__repr__ in Python 3.2

2010-07-29 Thread Raymond Hettinger
>> When you proposed the idea at EuroPython, it seemed reasonable >> but we didn't go into the pros and cons. The downsides include >> breaking tests, changing the output of report generating scripts >> that aren't using string formatting, and it introduces another >> inter-version incompatibilit

[Python-Dev] proto-pep: plugin proposal (for unittest)

2010-07-29 Thread Michael Foord
Hello all, My apologies in advance if email mangles whitespace in the code examples. I can reformulate as a PEP if that is deemed useful and this document can be found online at: http://hg.python.org/unittest2/file/tip/description.txt (Please excuse errors and omissions - but do feel fre

Re: [Python-Dev] proto-pep: plugin proposal (for unittest)

2010-07-29 Thread Michael Foord
Damn, the email was truncated. Probably my fault. The part missed off is: Not Yet Implemented === Except where noted, everything in this document is already working in the prototype. There are a few open issues and things still to be implemented. Certain event attributes sho

Re: [Python-Dev] Thoughts fresh after EuroPython

2010-07-29 Thread Benjamin Peterson
2010/7/29 Nick Coghlan : > On Thu, Jul 29, 2010 at 8:57 AM, Jesse Noller wrote: >> I thought at the last two pycons, we've all discussed that we should >> have a system in place for marking tests *and* modules within the >> stdlib as "will only work on FooPython". I suspect that it's waiting >> on

Re: [Python-Dev] Proposal: make float.__str__ identical to float__repr__ in Python 3.2

2010-07-29 Thread Benjamin Peterson
2010/7/29 Raymond Hettinger : > >>> When you proposed the idea at EuroPython, it seemed reasonable >>> but we didn't go into the pros and cons.  The downsides include >>> breaking tests, changing the output of report generating scripts >>> that aren't using string formatting, and it introduces anot

Re: [Python-Dev] Full unicode support for the import machinery

2010-07-29 Thread Victor Stinner
Le vendredi 09 juillet 2010 02:11:35, Victor Stinner a écrit : > I'm trying to fix Python to support undecodable bytes in the Python path > (...) My work is mostly done. I posted a patch on Rietveld and opened an issue. http://bugs.python.org/issue9425 http://codereview.appspot.com/1874048 --

Re: [Python-Dev] Proposal: make float.__str__ identical to float__repr__ in Python 3.2

2010-07-29 Thread Guido van Rossum
On Thu, Jul 29, 2010 at 3:30 PM, Raymond Hettinger wrote: > It also really calls into question whether there are good > reasons for other types to have a __str__ that is different > than their __repr__. Maybe, but there is tons of 3rd party code that uses this distinction. -- --Guido van Rossum

Re: [Python-Dev] Proposal: make float.__str__ identical to float__repr__ in Python 3.2

2010-07-29 Thread Alexander Belopolsky
On Thu, Jul 29, 2010 at 6:30 PM, Raymond Hettinger wrote: .. > It also really calls into question whether there are good > reasons for other types to have a __str__ that is different > than their __repr__. For strings, the distinction is very useful. In this and many other cases unifying str and