Re: [Python-Dev] str(memoryview('abc')) != 'abc' in Python 2.7
Nick Coghlan wrote: > I wouldn't assume so - memoryview is meant to eventually support more > than just 1-D views of contiguous memory (see PEP 3118), so that > conversion doesn't seem intuitive to me. In the example I'm passing in a single dimension contiguous memory chunk to memoryview(), so in that case I would expect str() of that memory chunk to return the same value and not the repr() of the object. buffer() already works like that. For non-contiguous memory views, the situation is less clear. AFAIK, non-contiguous views are mostly used to provide a non-copying view on a subset of multi-dimensional data, e.g. access to a row or column of a matrix, so the str() should probably return a contiguous copy of the selected data. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jul 15 2010) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ 2010-07-19: EuroPython 2010, Birmingham, UK 3 days to go ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python-checkins replies
On Tue, Jul 13, 2010 at 2:42 AM, Michael Foord wrote: >>> >>> Given how high traffic python-checkins is I don't consider that a >>> reasonable place to send follow-up and nor do I consider it the >>> responsibility of committers to monitor it. As you said earlier this >>> *isn't* in our standard dev procedures and nor do I think it should be. >>> If you can't find an email address then either python-comitters or >>> python-dev would be a better place to send feedback. >> >> Maybe reply-to on the checkin messages could be set to python-dev. Not >> sure if that's a mailman feature, though. > > I think this would be a good idea. It would be nice to have on-topic traffic > here. :-) +1 FWIW. It is a good practice to make code reviews public. It teaches people the proper ways and encourages to participate in reviews. -- anatoly t. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Removing IDLE from the standard library
On Thu, Jul 15, 2010 at 09:23:06AM +1000, Nick Coghlan wrote: > I use tabbed editors all the time (Kate, Notepad++) and find them to > be excellent. Tastes will obviously vary though, since there are even > people out there that use vim and emacs voluntarily ;) Sorry for being a wet blanket but vim implements tabbed windows even in console (text) mode. (-: Oleg. -- Oleg Broytmanhttp://phd.pp.ru/[email protected] Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] How to spell PyInstance_NewRaw in py3k?
On Wed, 14 Jul 2010 19:24:28 -0400 Alexander Belopolsky wrote: > I am reposting the same question again because it seems to have gone > unnoticed. Antoine Pitrou and I had a brief discussion on the > tracker, but did not reach an agreement on whether a more elaborate > code is needed to replace PyInstance_NewRaw than a simple > type->tp_alloc() call. > > I have reviewed the patch again and I am convinced that this issue > comes into play only when 3.x loads 2.x pickles that contain instances > of classic classes. (Specifically, this code is used to process INST > and OBJ pickle opcodes that are not produced by 3.x.) This means that > Antoine's concern that "tomorrow [object_new()] may entail additional > operations" is not valid - there is no tomorrow for 2.x. :-) But there *is* a tomorrow in 3.x and that's what we are talking about. Your code is meant to emulate object_new() in 3.x. > This > also means that the type cannot inherit from anything other than > object and thus cannot have funny tp_flags or tp_alloc that does not > create a usable object. Why can't it inherit from something else than object? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str(memoryview('abc')) != 'abc' in Python 2.7
On Thu, 15 Jul 2010 00:43:49 +0200
"M.-A. Lemburg" wrote:
> Is this intended or should I open a bug report for it:
>
> >>> m = memoryview('abc')
> >>> m == 'abc'
> True
> >>> str(m) == 'abc'
> False
> >>> str(m)
> ''
Well, I think this is intended. str(m) is the human-readable string
representation of the memoryview. In 3.x, you would write bytes(m)
instead to have its bytes contents.
Or, better again, use m.tobytes() in both versions.
Regards
Antoine.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] importlib
On Thu, Jul 15, 2010 at 4:06 PM, Brett Cannon wrote: >> In any case, here my results under a Linux system: >> >> $ ./python -m importlib.test.benchmark >> sys.modules [ 323782 326183 326667 ] best is 326667 >> Built-in module [ 33600 33693 33610 ] best is 33693 >> >> $ ./python -m importlib.test.benchmark -b >> sys.modules [ 1297640 1315366 1292283 ] best is 1315366 >> Built-in module [ 58180 57708 58057 ] best is 58180 > > And this is what might make evaluating importlib tough; while the > performance is 25% of what it is for import.c, being able to import > over 300,000 times/second is still damn fast. Yeah, I think the numbers where the filesystem gets involved are going to be more relevant. Modules that have already been cached and those built in to the executable aren't likely to dominate interpreter and application startup times (which is the main thing I'm worried about seeing regress). Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Removing IDLE from the standard library
On Thu, Jul 15, 2010 at 7:23 PM, Oleg Broytman wrote: > Sorry for being a wet blanket but vim implements tabbed windows even in > console (text) mode. (-: Oh, I know vim and emacs are actually incredibly powerful once you learn how to use them. I'm just a child of the GUI generation and believe UIs should be readily discoverable in accordance with http://xkcd.com/627/. I've tried to apply that technique to both applications in the past and failed miserably (although I will admit I haven't had the inclination to even try to use either of them for years now). Neither really strikes me as just a text editor, but more a way of life ;) Anyway, to bring this back on topic... Neither Kate nor Notepad++ allow you to easily move documents between windows (you have to open them explicitly in the second window). I had never noticed the lack until I explicitly checked for it after Stephen's last email. I suspect whether you consider this a must have feature or not depends greatly on your personal workflow when coding. If IDLE were to adopt a tabbed view without easy migration between separate windows, it would have plenty of company. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] notifications form Hg to python-checkins
[Nick] >[me] >> IIRC, you can’t know who pushed without kludgy hackery. > > [...] Note that the current distutils2 emails to python-checkins > already say "Tarek Ziade pushed..." I looked at mail.py in the hooks repository and learned that hooks get an HGPUSHER variable in their environment. Nice! Regards ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] How to spell PyInstance_NewRaw in py3k?
On Thu, Jul 15, 2010 at 6:29 AM, Antoine Pitrou wrote: > On Wed, 14 Jul 2010 19:24:28 -0400 > Alexander Belopolsky wrote: .. >> This means that >> Antoine's concern that "tomorrow [object_new()] may entail additional >> operations" is not valid - there is no tomorrow for 2.x. :-) > > But there *is* a tomorrow in 3.x and that's what we are talking about. > Your code is meant to emulate object_new() in 3.x. > Yes, I realized that after I hit the sent button. However, it is 2.x classic instances that are being unpickled and it won't be reasonable for 3.x objects that are expected to emulate them to do anything non-trivial. The need to be able to faithfully emulate classic instances unpickled from 2.x may be a valid constraint to future object_new() evolution. >> This >> also means that the type cannot inherit from anything other than >> object and thus cannot have funny tp_flags or tp_alloc that does not >> create a usable object. > > Why can't it inherit from something else than object? Because this would not be a reasonable way to forward port 2.x classic classes and expect them to interoperate with 2.x pickles. There are many ways to break unpickling of old pickles by modifying the class in the new version of code. The serious question for me is whether a valid tp_alloc can create a partially initialized object that will crash the interpreter when its method is called. I don't think this is the case because certainly you need to be able to delete the object if tp_new fails and that can call arbitrary code. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] importlib
On Thu, Jul 15, 2010 at 2:55 PM, Nick Coghlan wrote: >>> In any case, here my results under a Linux system: >>> >>> $ ./python -m importlib.test.benchmark >>> sys.modules [ 323782 326183 326667 ] best is 326667 >>> Built-in module [ 33600 33693 33610 ] best is 33693 >>> >>> $ ./python -m importlib.test.benchmark -b >>> sys.modules [ 1297640 1315366 1292283 ] best is 1315366 >>> Built-in module [ 58180 57708 58057 ] best is 58180 >> >> And this is what might make evaluating importlib tough; while the >> performance is 25% of what it is for import.c, being able to import >> over 300,000 times/second is still damn fast. > > Yeah, I think the numbers where the filesystem gets involved are going > to be more relevant. Modules that have already been cached and those > built in to the executable aren't likely to dominate interpreter and > application startup times (which is the main thing I'm worried about > seeing regress). What about web-applications? Is that true that for FastCgi or mod_wsgi deamon mode interpreter and application is started only once per say 100 requests? -- anatoly t. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Whither 'trunk'
The 'trunk' branch appears to have been frozen 12 days ago when 2.7 was released. I presume py3k is now the main development branch. Correct? There are doc(s) on the site the directed people to the 'trunk' branch. If not updated (as seems from a python-list post today, but I asked the OP), it/they should be. -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Removing IDLE from the standard library
On 07/15/2010 07:13 AM, Nick Coghlan wrote: On Thu, Jul 15, 2010 at 7:23 PM, Oleg Broytman wrote: Sorry for being a wet blanket but vim implements tabbed windows even in console (text) mode. (-: Oh, I know vim and emacs are actually incredibly powerful once you learn how to use them. I'm just a child of the GUI generation and believe UIs should be readily discoverable in accordance with http://xkcd.com/627/. I've tried to apply that technique to both applications in the past and failed miserably (although I will admit I haven't had the inclination to even try to use either of them for years now). Neither really strikes me as just a text editor, but more a way of life ;) Anyway, to bring this back on topic... Neither Kate nor Notepad++ allow you to easily move documents between windows (you have to open them explicitly in the second window). I had never noticed the lack until I explicitly checked for it after Stephen's last email. I suspect whether you consider this a must have feature or not depends greatly on your personal workflow when coding. If IDLE were to adopt a tabbed view without easy migration between separate windows, it would have plenty of company. My preference would to just have two tabs and/or panes per window. One for the source listing and one for the command interface. It's easy enough to have multiple idle windows open and cut and copy between them. The file window could have an "open in new window" option which would start a new idle instance. That keeps things simple and would be easy enough to understand by the majority of new/novice to computer/programming users. It also avoid having the command window shared by multiple programs which could cause all sorts of messy output or errors if multiple scripts are being run at the same time. Ron ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] profiler decorator - is it worth for inclusion?
Today I was looking for a quick and dirty way to profile a method of a class. I was thinking that cProfile module had a decorator for this but I was wrong so I decided to write one based on hotshot. Would it be worth for inclusion? #!/usr/bin/env python import hotshot import hotshot.stats import tempfile import pstats def profile(sort='cumulative', lines=30, strip_dirs=False): """A decorator which profiles a callable. Example usage: >>> @profile() ... def factorial(n): ... n = abs(int(n)) ... if n < 1: ... n = 1 ... x = 1 ... for i in range(1, n+1): ... x = i * x ... return x ... >>> factorial(5) 1 function calls in 0.000 CPU seconds Ordered by: internal time, call count ncalls tottime percall cumtime percall filename:lineno(function) 10.0000.0000.0000.000 profiler.py:60(factorial) 00.000 0.000 profile:0(profiler) 120 >>> """ def outer(fun): def inner(*args, **kwargs): file = tempfile.NamedTemporaryFile() prof = hotshot.Profile(file.name) try: ret = prof.runcall(fun, *args, **kwargs) finally: prof.close() stats = hotshot.stats.load(file.name) if strip_dirs: stats.strip_dirs() if isinstance(sort, tuple): stats.sort_stats(*sort) else: stats.sort_stats(sort) stats.print_stats(lines) return ret return inner return outer ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] profiler decorator - is it worth for inclusion?
On Thu, Jul 15, 2010 at 13:45, Giampaolo Rodolà wrote: > Today I was looking for a quick and dirty way to profile a method of a > class. > I was thinking that cProfile module had a decorator for this but I was > wrong so I decided to write one based on hotshot. > Would it be worth for inclusion? Since hotshot is gone in 3.x, I'd guess the chances are probably slim. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] profiler decorator - is it worth for inclusion?
2010/7/15 Brian Curtin : > On Thu, Jul 15, 2010 at 13:45, Giampaolo Rodolà wrote: >> >> Today I was looking for a quick and dirty way to profile a method of a >> class. >> I was thinking that cProfile module had a decorator for this but I was >> wrong so I decided to write one based on hotshot. >> Would it be worth for inclusion? > > Since hotshot is gone in 3.x, I'd guess the chances are probably slim. > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/g.rodola%40gmail.com > > Here's one using cProfile instead. I was using hotshot because I wasn't aware of cProfile.Profile.runcall which is currently not documented (I'm going to file a bug report). def profile(sort='cumulative', lines=30, strip_dirs=True): """A decorator which profiles a callable. Example usage: >>> @profile() ... def factorial(n): ... n = abs(int(n)) ... if n < 1: ... n = 1 ... x = 1 ... for i in range(1, n+1): ... x = i * x ... return x ... >>> factorial(5) Thu Jul 15 20:58:21 2010/tmp/tmpIDejr5 4 function calls in 0.000 CPU seconds Ordered by: internal time, call count ncalls tottime percall cumtime percall filename:lineno(function) 10.0000.0000.0000.000 profiler.py:120(factorial) 10.0000.0000.0000.000 {range} 10.0000.0000.0000.000 {abs} 10.0000.0000.0000.000 {method 'disable' of '_lsprof.Profiler' objects} 120 """ def outer(fun): def inner(*args, **kwargs): file = tempfile.NamedTemporaryFile() prof = cProfile.Profile() try: ret = prof.runcall(fun, *args, **kwargs) except: file.close() raise prof.dump_stats(file.name) stats = pstats.Stats(file.name) if strip_dirs: stats.strip_dirs() if isinstance(sort, tuple): stats.sort_stats(*sort) else: stats.sort_stats(sort) stats.print_stats(lines) file.close() return ret return inner return outer --- Giampaolo http://code.google.com/p/pyftpdlib http://code.google.com/p/psutil ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Removing IDLE from the standard library
On Thu, Jul 15, 2010 at 5:13 AM, Nick Coghlan wrote: > On Thu, Jul 15, 2010 at 7:23 PM, Oleg Broytman wrote: >> Sorry for being a wet blanket but vim implements tabbed windows even in >> console (text) mode. (-: > > Oh, I know vim and emacs are actually incredibly powerful once you > learn how to use them. I'm just a child of the GUI generation and > believe UIs should be readily discoverable in accordance with > http://xkcd.com/627/. I've tried to apply that technique to both > applications in the past and failed miserably (although I will admit I > haven't had the inclination to even try to use either of them for > years now). Neither really strikes me as just a text editor, but more > a way of life ;) > > Anyway, to bring this back on topic... > > Neither Kate nor Notepad++ allow you to easily move documents between > windows (you have to open them explicitly in the second window). I had > never noticed the lack until I explicitly checked for it after > Stephen's last email. I suspect whether you consider this a must have > feature or not depends greatly on your personal workflow when coding. > If IDLE were to adopt a tabbed view without easy migration between > separate windows, it would have plenty of company. It might be, but I'll admit that my work habits (used to be all-vim-all-the-time) have changed substantially since finding the joy of gedit's tab system (and plugins). Something along these lines is probably necessary to be competitive, at least on Linux. Geremy Condra ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] importlib
anatoly techtonik wrote: What about web-applications? Is that true that for FastCgi or mod_wsgi deamon mode interpreter and application is started only once per say 100 requests? Yes. Only CGI programs reload on every use. FCGI/WSGI programs run more or less forever, and are only loaded once, reading requests and handling them. Some FCGI systems reload their applications once in a while, and ask the idle ones to exit after periods of no traffic, but that's a form of automatic performance tuning. And, of course, there are the permanently resident systems like Twisted. (Incidentally, if you run FCGI/WSGI programs under Apache, make sure that you don't put .fcgi scripts in a directory from which Apache will execute .cgi scripts. Apache will run the .fcgi script with CGI, and the WSGI Python module will detect this and run the script one time and exit for each request. Everything appears to work and performance is terrible.) If import performance is important in a production server environment, it's more useful to look at minimizing the number of loads rather than trying to make them faster. If and when Unladen Swallow finally gets going, startup times will get worse as the JIT compiler cranks, but run time will (hopefully) decrease. John Nagle ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Removing IDLE from the standard library
Neil Hodgson wrote: > Stephen J. Turnbull: > >> But it's very important to be able to *move* tabs across windows or >> panes. ... >> In many apps, however, you would have to select the foo.c tab, close >> it, bring up a new window, and open foo.c using the long path >> (presumably with a file browser interface, but often enough the >> default directory is wherever you started the editor, not most >> recently used file). > >The common GUI technique is to drag a tab from one window into > another window. Drag onto the desktop for a new top level > window. This is supported by, among others, Firefox; Chrome; gedit; > and GNOME Terminal. > Time used to be we would innovate, not imitate, but I suppose that convergence has changed things. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 DjangoCon US September 7-9, 2010http://djangocon.us/ See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Whither 'trunk'
On Thu, Jul 15, 2010 at 09:19, Terry Reedy wrote: > The 'trunk' branch appears to have been frozen 12 days ago when 2.7 was > released. I presume py3k is now the main development branch. Correct? > Yes. > There are doc(s) on the site the directed people to the 'trunk' branch. If > not updated (as seems from a python-list post today, but I asked the OP), > it/they should be. What pages? I thought I updated the developer docs, but maybe I only did the dev FAQ. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] versioned .so files for Python 3.2
Hello, 2010/7/15 Barry Warsaw : > The first draft of PEP 3149 is ready for review. I like it! I think it could mention the case where packages are not installed in the canonical directory, but placed elsewhere along the PYTHONPATH. This is how I deploy applications, for example, and the differences between python versions makes this a pain. The specific case of Windows should be mentioned: each foo.pyd contains the name of the python library (Python27.dll) it has been linked with; It must be rebuilt for a major version change. IMO the Windows installers provided by python.org should be built with a tag that contains this major number. > Thus for example, an initial implementation of PEP 384, compiled with > `--with-so-abi-tag=cpython-xy` would search for the following file > names when extension module `foo` is imported (in this order):: > > foo.abi3.so > foo.cpython-xy.so > foo.so Is this the correct order? IMO the so-abi-tag is more precise and the two first items should be swapped. PyPy would also benefit from this patch: it can now use extension modules, but the ABI is slightly different. By default, PyPy would load only modules containing the ABI tag, and refuse foo.so which is incompatible for sure. But the installations could still be shared between Python implementations. Cheers, -- Amaury Forgeot d'Arc ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Removing IDLE from the standard library
On Thu, Jul 15, 2010 at 2:04 PM, Steve Holden wrote: > Neil Hodgson wrote: >> Stephen J. Turnbull: >> >>> But it's very important to be able to *move* tabs across windows or >>> panes. ... >>> In many apps, however, you would have to select the foo.c tab, close >>> it, bring up a new window, and open foo.c using the long path >>> (presumably with a file browser interface, but often enough the >>> default directory is wherever you started the editor, not most >>> recently used file). >> >> The common GUI technique is to drag a tab from one window into >> another window. Drag onto the desktop for a new top level >> window. This is supported by, among others, Firefox; Chrome; gedit; >> and GNOME Terminal. >> > Time used to be we would innovate, not imitate, but I suppose that > convergence has changed things. Nobody is being innovative with IDLE's UI right now. Some imitation would do it good, however. Geremy Condra ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
