Rookie Question: Passing a nested list into a function?
I am trying to pass the value of a nested list into a function (to my "if" statement) as follows: textfilelist = [["titlelist1[x][1]"]] def idfer(listlength, comparelistlength, list): while x < (listlength - 1): while y < comparelistlength: if list == titlelist2[y][1]: (I cutoff the end to focus on the problem) #Here i call my function hoping i am passing the value within textfilelist[0][0] to my function idfer(textfilelist[0][1], textfilelist[1][1], textfilelist[0][0]) -- I don't if there is a "legal" way to do this, but I would appreciate some guidance. Thanks, Brett -- http://mail.python.org/mailman/listinfo/python-list
Re: Rookie Question: Passing a nested list into a function?
I think so. I later reference it as textfilelist[0][0]. My intent is to be able to use: titlelist1[x][1] as part of my "if" statement in my function. -Brett "James Stroud" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > Do you really want quotation marks around "titlelist1[x][1]" ? > > e.g. > >>>> textfilelist = [["titlelist1[x][1]"]] >>>> textfilelist[0][1] > Traceback (most recent call last): > File "", line 1, in ? > IndexError: list index out of range > > > > On Thursday 14 April 2005 06:51 pm, Brett wrote: >> I am trying to pass the value of a nested list into a function (to my >> "if" >> statement) as follows: >> >> textfilelist = [["titlelist1[x][1]"]] >> def idfer(listlength, comparelistlength, list): >> while x < (listlength - 1): >>while y < comparelistlength: >> if list == titlelist2[y][1]: >> (I cutoff the end to focus on the problem) >> >> #Here i call my function hoping i am passing the value within >> textfilelist[0][0] to my function >> idfer(textfilelist[0][1], textfilelist[1][1], textfilelist[0][0]) >> >> >> -- >> I don't if there is a "legal" way to do this, but I would appreciate some >> guidance. >> >> Thanks, >> >> Brett > > -- > James Stroud, Ph.D. > UCLA-DOE Institute for Genomics and Proteomics > Box 951570 > Los Angeles, CA 90095 > > http://www.jamesstroud.com/ -- http://mail.python.org/mailman/listinfo/python-list
odd mmap behavior
I'm trying to read and write from /dev/mem on a linux system using the
mmap module. When I run this minimal example:
---
import os, mmap
MAP_MASK = mmap.PAGESIZE - 1
addr = 0x48088024
f = os.open("/dev/mem", os.O_RDWR | os.O_SYNC)
m = mmap.mmap(f, mmap.PAGESIZE, mmap.MAP_SHARED, mmap.PROT_WRITE |
mmap.PROT_READ, offset=addr & ~MAP_MASK)
m.seek(addr & MAP_MASK)
c = m.read_byte()
print c
m.close()
os.close(f)
---
I get the following error:
Unhandled fault: external abort on non-linefetch (0x1018) at
0x40020024
Bus error
and python crashes. What is odd is that if I try to read the same
memory address using the devmem2 program (i'll attach the source at
the end), everything works fine. Here are the truncated straces for
each program:
- devmem2 0x48088024 -
open("/dev/mem", O_RDWR|O_SYNC) = 3
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x4001f000
write(1, "/dev/mem opened.\n", 17) = 17
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x48088) =
0x4002
write(1, "Memory mapped at address 0x40020"..., 37) = 37
write(1, "Value at address 0x48088024 (0x4"..., 46) = 46
munmap(0x4002, 4096)= 0
close(3)= 0
io_submit(0, 0, 0xfbad2088
Process 1635 detached
-- the above minimal python example -
open("/dev/mem", O_RDWR|O_SYNC|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFCHR|0640, st_rdev=makedev(1, 1), ...}) = 0
dup(3) = 4
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x48088) =
0x4002
--- SIGBUS (Bus error) @ 0 (0) ---
+++ killed by SIGBUS +++
Process 1633 detached
Am I using mmap incorrectly?
--
http://mail.python.org/mailman/listinfo/python-list
Re: odd mmap behavior
On Oct 21, 8:02 am, Carl Banks wrote:
> On Oct 20, 5:03 pm, Brett wrote:
>
>
>
> > I'm trying to read and write from /dev/mem on a linux system using the
> > mmap module. When I run this minimal example:
> > ---
> > import os, mmap
>
> > MAP_MASK = mmap.PAGESIZE - 1
>
> > addr = 0x48088024
>
> > f = os.open("/dev/mem", os.O_RDWR | os.O_SYNC)
> > m = mmap.mmap(f, mmap.PAGESIZE, mmap.MAP_SHARED, mmap.PROT_WRITE |
> > mmap.PROT_READ, offset=addr & ~MAP_MASK)
> > m.seek(addr & MAP_MASK)
> > c = m.read_byte()
> > print c
> > m.close()
> > os.close(f)
> > ---
>
> > I get the following error:
> > Unhandled fault: external abort on non-linefetch (0x1018) at
> > 0x40020024
> > Bus error
>
> > and python crashes. What is odd is that if I try to read the same
> > memory address using the devmem2 program (i'll attach the source at
> > the end), everything works fine. Here are the truncated straces for
> > each program:
>
> > - devmem2 0x48088024 -
> > open("/dev/mem", O_RDWR|O_SYNC) = 3
> > fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
> > mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> > 0) = 0x4001f000
> > write(1, "/dev/mem opened.\n", 17) = 17
> > mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x48088) =
> > 0x4002
> > write(1, "Memory mapped at address 0x40020"..., 37) = 37
> > write(1, "Value at address 0x48088024 (0x4"..., 46) = 46
> > munmap(0x4002, 4096) = 0
> > close(3) = 0
> > io_submit(0, 0, 0xfbad2088
> > Process 1635 detached
>
> > -- the above minimal python example -
> > open("/dev/mem", O_RDWR|O_SYNC|O_LARGEFILE) = 3
> > fstat64(3, {st_mode=S_IFCHR|0640, st_rdev=makedev(1, 1), ...}) = 0
> > dup(3) = 4
> > mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x48088) =
> > 0x4002
> > --- SIGBUS (Bus error) @ 0 (0) ---
> > +++ killed by SIGBUS +++
> > Process 1633 detached
>
> > Am I using mmap incorrectly?
>
> Looks like you're using it ok to me.
>
> One thing to keep in mind is that the offset parameter was added to
> mmap recently, only in Python 2.6 I think, so it might not have been
> so battle-tested as the rest of Python. Also, I would guess the file-
> like methods (seek, read, etc.) are not commonly used. Perhaps those
> methods don't play nice with the offset method? It's possible the
> mmap object doesn't recon the seek pointer relative to the offset,
> meaning you'd have to use m.seek(addr) instead of m.seek(addr &
> MAP_MASK)
>
> Another possibility is that the mmap object is accessing the memory
> with bad alignment (when I see bus error the first thing I think of is
> that a word was read from a non-word-aligned address). You don't
> happen to be running this on a Power PC? What happens when you try
> accessing the mmap data like an regular array?
>
> All speculation, but my gut feeling is bug in mmap module.
>
> Carl Banks
I also posted this question to the linux-omap list and received some
helpful (and timely) assistance. I'm running this on an ARM (omap
3530, gumstix). Here is the take-home message (from the omap technical
reference and reported to me here
http://www.spinics.net/lists/linux-omap/msg19347.html):
"CAUTION
The GP timer registers are limited to 32-bit and 16-bit data accesses;
8-bit access is not allowed and can corrupt the register content."
So... instead of calling mmap.read_byte() i'm calling mmap.read(4).
The thing I'm still wondering, is if python 'under-the-hood' is still
making 8-bit accesses. I thought it was fixed, but just got another
'Unhandled fault'. Any hints?
Also, thanks for the suggestion about accessing it as an array. I will
try to find out if one method of access (array-like or reading as a
string) results in more errors.
--
http://mail.python.org/mailman/listinfo/python-list
Error when deleting and reimporting subpackages
Hi, I recently ran into this behavior: >>> import sys >>> import apkg.subpkg >>> del sys.modules['apkg'] >>> import apkg.subpkg as subpkg Traceback (most recent call last): File "", line 1, in AttributeError: 'module' object has no attribute 'subpkg' where 'apkg' and 'subpkg' comprise empty __init__.py files to simplify the example. It appears then, that importing a subpackage, then deleting the containing package from sys.modules, orphans the subpackage in an unfixable state. I ran into this because the nose testing framework does exactly this kind of thing when loading test modules, causing some very confusing errors and failures. Is this behavior expected? Best, Matthew -- http://mail.python.org/mailman/listinfo/python-list
Re: Error when deleting and reimporting subpackages
On Monday, August 22, 2011 12:06:44 PM UTC-7, Stephen Hansen wrote: > On 8/22/11 11:51 AM, Matthew Brett wrote: > > Hi, > > > > I recently ran into this behavior: > > > >>>> import sys > >>>> import apkg.subpkg > >>>> del sys.modules['apkg'] > >>>> import apkg.subpkg as subpkg > > Traceback (most recent call last): > > File "", line 1, in > > AttributeError: 'module' object has no attribute 'subpkg' > > > > where 'apkg' and 'subpkg' comprise empty __init__.py files to simplify the > > example. > > > > It appears then, that importing a subpackage, then deleting the containing > > package from sys.modules, orphans the subpackage in an unfixable state. > > > > I ran into this because the nose testing framework does exactly this kind > > of thing when loading test modules, causing some very confusing errors and > > failures. > > > > Is this behavior expected? > > Yes. Doing an import of "apkg.subpkg" results in more then just "test1" > being cached in sys.modules, and you're removing half of that so leaving > Python in a weird state. > > You also want to del sys.modules["apkg.subpkg"], then you'll be able to > re-import apkg.subpkg. I.e: > > Python 2.7.1 (r271:86882M, Nov 30 2010, 10:35:34) > [GCC 4.2.1 (Apple Inc. build 5664)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import sys > >>> import test1.test2 > >>> del sys.modules['test1'] > >>> del sys.modules['test1.test2'] > >>> import test1.test2 as test2 > >>> Yes, sorry, I should have mentioned that I explored these kind of variations. I think I see that there isn't an obvious way for del sys.modules['apkg'] to know to delete or modify 'apkg.subpkg', because sys.modules is just a dict. However, I could imagine the import machinery being able to recognize that 'apkg.subpkg' is broken, and re-import it without error. Is that reasonable? Best, Matthew -- http://mail.python.org/mailman/listinfo/python-list
Re: Software to Control RGB Strips
On Friday, January 13, 2017 at 1:07:40 PM UTC-5, Brett Salyer wrote: > Hey all, > > I was debating on getting some RGB light strips for my room. I noticed, from > this tutorial: > > http://popoklopsi.github.io/RaspberryPi-LedStrip/#!/ws2812 > > > there is a WS2812x library to run commands that control the RGB strip. Well, > I wanted to, instead of running commands through a terminal, create a GUI > using python, then exploit the library I mentioned above to create a piece of > software that controls my lighting from my Raspberry Pi. > > I was going to use Tkinter to create the GUI. > > Now, I'm a pretty beginner programmer, having only taken a C++ course and the > Java course I'm in now. > > Do I just need to download the WS2812x library, and, then, access that > library as I would, say, a header file in C++? In Pythons syntax, of course. > > Anything to get me pointed in the right direction would be greatly > appreciated! Thanks! Thanks a lot, man! -- https://mail.python.org/mailman/listinfo/python-list
Re: [Python-ideas] Enhancing Zipapp
Thanks for the ideas, Abdur-Rahmaan! Some feedback below. On Mon, Jan 6, 2020 at 11:35 AM Abdur-Rahmaan Janhangeer < arj.pyt...@gmail.com> wrote: > Note: draft simplified > > Abstract > == > > This extracts aims at proposing enhancements to the generated zipapp > executable > > Rationale > === > > One area where there remains some difficulty in Python is packaging for > end-user consumption. To that effect either the code is distributed in pure > Python form with installers [1] or native executables are built for each > target > Os [2]. Currently by default, Python does not provide such utilities. This > pro- > posal aims at finalising a Python-specific archive as the default VM exec- > utable built on zipapp. > > In simple terms, it proposes to enhance zipapp from plain archive to > app-level > archive. > > Advantages of archives > == > > Archives provide a great way to publish software that needs to be > distributed as > a single file script but is complex enough to need to be written as a > collection of > modules [3] > > You can use archives for tasks such as lossless data compression, > archiving, > decompression, and archive unpacking. [4] Adding capabilities like digital > signing is used to verify integrity and authenticity. > > Zip archives as apps > > > If we are to treat zip archives as app, here are some recommended features > > - [x] Main entry point > > A main entry point specifies which file to launch. Zipapp already solves > this > problem by either having a __main__.py [5] or specifying the entry point > at the > commandline ENTRYPOINT_MODULE:ENTRYPOINT_FUNCTION [6] > > - [ ] App info file > > An info file can have info such as author name, archiving date, company > name > etc. > This would be a packaging detail so not something to be specified in the stdlib. > > - [ ] Signing mechanism > > Mechanisms can be added to detect the integrity of the app. App hash can > be > used to check if the app has been modified and per-file hash can be used > to > detect what part has been modified. This can be further enhanced if needed. > > - [ ] Protecting meta data > > Metadata are not protected by basic signing. There existing ways to protect > metadata and beyond [7] > This can be tricky because people want signing in specific ways that vary from OS to OS, case by case. So unless there's a built-in signing mechanism the flexibility required here is huge. > > - [x] Pure-Python 3rd party package bundling > > In Python, as long as the 3rd party packages are pure-python packages, we > can bundle and use them [6]. The user can maybe just include a > requirements.txt > > - [ ] C-based 3rd party packages > > Zipapp by default was not meant to include packages at all. > > << The executable zip format is specifically designed for standalone use, > without needing to be installed. They are in effect a multi-file version > of a > standalone Python script >> > > Though the previous point shows that this can be done. Now remains the > issue of C-based packages. Distributing wheels might be the answer [8]. > A zip archive is supposed to be standalone. A possible solution might be > to > include wheels and the wheels are installed in a site-packages folder. > > When running such an app, the interpreter will check first if the > app-specific > site-packages folder is empty, if not, install the wheels. This provides > package- > freezing ability. The only downside is longer first-run time. > Install the wheels where? You can't do that globally. And you also have to worry about the security of doing the install implicitly. And now the user suddenly has stuff on their file system they may not have asked for as a side-effect which may upset some people who are tight on disk space (remember that Python runs on some low-powered machines). -Brett > > Only specifying packages to be installed is not an option as if you really > want > stand-alone apps, using the internet etc defeats the purpose. > > FAQ > > > Why not a package manager? > --- > The zipapp pep was introduced for a reason, for easing the running of > archives. > Maybe the package manager idea came from listening to people talking about > packaging and pex and comparing it with package-managers like homebrew > and concluded that pex and hence zipapp is not worth it and people would > better off not complicate their lives with some zip utility. > > This proposal is not solving any problem at all > -- > This proposal aims
Re: number of python users
RHEL isn't really "big" on Distrowatch because Distrowatch is geared more towards users. RHEL 4.1 is using Python 2.3.4 now, btw. -- http://mail.python.org/mailman/listinfo/python-list
Re: What tools are used to write and generate Python Librarydocumentation.
You get to spend all day in ipython? Can I have your job? -- http://mail.python.org/mailman/listinfo/python-list
Re: Set up Windows environment with python
I don't have experience with scipting this... but I know that resolution for example is stored in registry, and _that_ is what is loaded when you boot. I think most, if not all, of your changes will be found in the registry (for permenance). Also, have you checked out PyWin32? It's just a big pre-made wrapper for the Win32 stuff, not sure if it will be more/less work than ctypes but it could make it easier on you. PyWin32 http://sourceforge.net/project/showfiles.php?group_id=78018 -- http://mail.python.org/mailman/listinfo/python-list
Re: How is wxWindows related to Python?
I guess it is referring to the closely related (maybe even same dev group? I don't know why the wxWindows docs would mention Python unless they specifically support the wxPython project, too.) "wxWindows + Python = wxPython wxPython is a Python extension module that provides a set of bindings from the wxWindows library to the Python language. In other words, the extension module allows Python programers to create instances of wxWindows classes and to invoke methods of those classes. More from this Chapter: · Using Tkinter · Using PythonWin The wxPython extension module attempts to mirror the class hierarchy of wxWindows as closely as possible. This means that there is a wxFrame class in wxPython that looks, smells, tastes, and acts almost the same as the wxFrame class in the C++ version. wxPython is close enough to the C++ version that the majority of the wxPython documentation is actually annotations to the C++ documentation that describe the places where wxPython is different. There is also a series of sample programs included, and a series of documentation pages that assist the programmer in getting started with wxPython. " http://www.onlamp.com/pub/a/python/excerpts/chpt20/wxpython.html http://www.wxpython.org/ -- http://mail.python.org/mailman/listinfo/python-list
Re: change a value to NULL?
I'm not sure what you mean, really, do you need an official Python "Null" value? Try None? In [6]: myCells = ['Mary', 'Bob', None, 'Joe'] In [7]: for cell in myCells: ...: if cell: ...: print cell ...: else: ...: print "NULL VALUE" ...: Mary Bob NULL VALUE Joe -- As far as having a Null value to put into the DB, most (SQL) DB's I've used have a specific SQL command like "INSERT INTO ROW VALUE NULL()", kind of like the SQL DATE(), etc. I'm really rusty on my syntax etc right now btw so don't copy and paste that. :P -- http://mail.python.org/mailman/listinfo/python-list
Re: best Pythonic way to do this sort: Python newb
(sorted is a built-in function in 2.4) def myFunction( data ): """ Take one of your set of 3, grab [2] (the 3rd) and do calcs, return value """ "do some math calculations to data[2]" return "result of calculations" sorted_list = sorted(myList, key=myFunction) List is sorted in the order of the 'key' values, key being a value returned from myFunction which operates on [2]. -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie needs help. Setting PYTHONDOCS to read HTML.
You can use Python regardless of the docs... of course. Not sure what you mean there. As far as setting an Environment Variable, though: (1) Right-Click My Computer, go to Properties (2) Go to the Advanced tab (3) Click Environment Variables (bottom middle-ish) (4) Under "User Variables" click New, (5) Variable name: PYTHONDOCS Variable value: C:\Python24 Of course, the value needs to be the correct folder that you said you dropped the HTML docs into. -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie needs help. Setting PYTHONDOCS to read HTML.
That's because the Python docs come zipped up within a folder, for example: python_docs.tar.bz2 has a folder inside it called Python-Docs-2.4.2. You need to have C:\Python24\Python-Docs-2.4.2\ as the value if thats where that folder is, or wherever you unzipped it. I, personally, just took all the directories out of Python-Docs-2.4.2 and put them in C:\Python24\Doc and then added C:\Python24\Doc as the value for PYTHONDOCS. Hope that made sense. -- http://mail.python.org/mailman/listinfo/python-list
Re: installer for amd64 build of python?
> Alternatively, does anyone have experience > of using the visual studio files in the PCBuild > directory under amd64? I don't have an answer for you, but just to clarity for future readers... based on the quote above, I assume you mean a native 64-bit build for Windows, right? You never stated what platform you need this for, I for one use a 64-bit build of Python on Linux just fine... but yes, Windows is another story, especially if you want it built with the super-mega-pro VS with optimizations and all that jazz they use for official 32-bit Windows binaries. -- http://mail.python.org/mailman/listinfo/python-list
Re: installer for amd64 build of python?
As an aside to this, are there any freely available C compilers for Windows that can compile 64-bit binaries? I find nothing for Cygwin or MinGW... -- http://mail.python.org/mailman/listinfo/python-list
Re: installer for amd64 build of python?
Trent Mick wrote: > Yes. The MS Platform SDK is free and includes a compiler that can target > x86, ia64 and x64 (the latter is what MS -- and Sun -- are calling > AMD64). Thanks, looking at their site I can't find a Platform SDK for XP... am I looking for the Windows 2003 Server SDK...? Seems counter-intuitive if so, but it does mention you can build 32 and 64-bit apps with it, I just assumed they would be uh, for Windows Server. Thanks again, Brett -- http://mail.python.org/mailman/listinfo/python-list
Re: Web based applications are possible with wxPython?
I don't think this is possible, unless I am grossly misunderstanding. For the web, pretty much every "UI" is build with some variation of HTML (XHTML is the new standard) with JavaScript thrown in for fancy GUI-like interfaces. You can't use OS-native widgets in the web browser, no. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python for .NET and IronPython
hrh1818 wrote: > For more information on Iron Python see http://www.ironpython.com/ > My take on Iron Python is the new job the develolper of Iron Python > started last year takes up just about all of his time and the developer > is currently spending very little time actively developing Iron Python. Actually, he just stopped updating ironpython.com (a bad idea, imo) apparently. Last release was 10/13 through Microsoft, http://www.microsoft.com/downloads/details.aspx?FamilyID=c6a7fee3-6495-427f-8b1f-768a2715170c&DisplayLang=en If that link doesn't work you can just search "IronPython" on microsoft.com Brett -- http://mail.python.org/mailman/listinfo/python-list
Re: putting an Icon in "My Computer"
> I've been asked by my boss to put an Icon in WinXP's "My Computer" for > a utility we use around the shop. My tool of choice is of course > Python and therefore what I am using to attempt my given task. I have > no trouble putting Icons in the WinXP Toolbar using Python, but have > totally failed to get an Icon to appear in My Computer. Any Idea on > why and maybe how to get around this using Python? I'm pretty sure the My Computer menu is limited to devices and special Windows folders like My Documents, etc. I've never seen a program add an icon there, and I don't think its allowed through the API. -- http://mail.python.org/mailman/listinfo/python-list
Re: How can I package a python script and modules into a single script?
Would PythonEggs be close? It's basically a zip format with all the Python files inside, it would maintain the structure and not be a single script file, but would be a single .egg file... the end user would just run the script and all would be installed, essentially. http://peak.telecommunity.com/DevCenter/PythonEggs -- http://mail.python.org/mailman/listinfo/python-list
Re: newbie - How do I import automatically?
> I have written some functions in a file called btools.py. I would like > to import them automatically when I start up Python shell. Today I must > do it by hand like this > > >>> from btools import * > >>> dir() > ['__builtins__', '__doc__', '__name__', 'func1', 'func2', 'func3'] > >>> > > Is there a way to do this automatically so that I always have 'func1', > 'func2' and so on available, without me having to do it by hand? This isn't _exactly_ what you wanted, but you might want to try using IPython, a much improved Python shell, http://ipython.scipy.org/ You can easily configure it to automatically import whatever kind of modules you want on start, etc... and it has many other features, I just can't picture touching the normal Python shell anymore. -- http://mail.python.org/mailman/listinfo/python-list
Re: Basic about Python class
Manuel11g wrote: > Hello, > I am a new programmer in Python and a need some help. Where can i get a > basic tutorial about Class. I don't know nothing about Object Oriented > Programming. Can you help me? http://diveintopython.org/object_oriented_framework/index.html -- http://mail.python.org/mailman/listinfo/python-list
Re: Favorite flavor of Linux? (for python or anything else)
I have to add another vote for Gentoo. I agree that you just "have less problems" on Gentoo. Updates are from source, but you don't have to update mid-day while working on a project... if you really want the new version of KDE (etc) then start an update and go to sleep, not a big deal. Portage (package management) is amazing, also... for both new and advanced users. Also, I don't use it for the CFLAGS, etc. If Gentoo were the same speed, or even mildly slower than Ubuntu, I would still use it. The general speed boost is just a bonus. I use very simple (-O2 -pipe) CFLAGS, by the way, but -march-pentium-m on my laptop makes a big difference over -mcpu-i386 distros. -- http://mail.python.org/mailman/listinfo/python-list
Re: new in programing
Efrain Marrero wrote:
> i want to now how to do this in python
> this is java
>
>
> for(int i=1 ; i<=lim ; i++){
>
> for(int j=i+1; j<=lim+1; j++){
>
> for(int k =j+1; k<=lim+2;k++){
>
> for(int l=k+1 ; l<=lim+3;l++){
>
> for(int m=l+1 ; m<=lim+4;m++){
>
> for(int o=m+1 ; o<=lim+5;o++){
That code wouldn't run on a JVM, do you have the rest? Or are we to
assume these loops do nothing and just close all the braces?
--
http://mail.python.org/mailman/listinfo/python-list
python-dev Summary for 2004-10-16 through 2004-10-31
This is a summary of traffic on the `python-dev mailing list`_ from October 16, 2004 through October 31, 2004. It is intended to inform the wider Python community of on-going developments on the list. To comment on anything mentioned here, just post to `comp.lang.python`_ (or email python-list@python.org which is a gateway to the newsgroup) with a subject line mentioning what you are discussing. All python-dev members are interested in seeing ideas discussed by the community, so don't hesitate to take a stance on something. And if all of this really interests you then get involved and join `python-dev`_! This is the fifty-first summary written by Brett Cannon (I *will* be caught up on summaries soon). To contact me, please send email to brett at python.org ; I do not have the time to keep up on comp.lang.python and thus do not always catch follow-ups posted there. All summaries are archived at http://www.python.org/dev/summary/ . Please note that this summary is written using reStructuredText_ which can be found at http://docutils.sf.net/rst.html . Any unfamiliar punctuation is probably markup for reST_ (otherwise it is probably regular expression syntax or a typo =); you can safely ignore it, although I suggest learning reST; it's simple and is accepted for `PEP markup`_ and gives some perks for the HTML output. Also, because of the wonders of programs that like to reformat text, I cannot guarantee you will be able to run the text version of this summary through Docutils_ as-is unless it is from the `original text file`_. .. _PEP Markup: http://www.python.org/peps/pep-0012.html The in-development version of the documentation for Python can be found at http://www.python.org/dev/doc/devel/ and should be used when looking up any documentation on new code; otherwise use the current documentation as found at http://docs.python.org/ . PEPs (Python Enhancement Proposals) are located at http://www.python.org/peps/ . To view files in the Python CVS online, go to http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/ . Reported bugs and suggested patches can be found at the SourceForge_ project page. The `Python Software Foundation`_ is the non-profit organization that holds the intellectual property for Python. It also tries to forward the development and use of Python. But the PSF_ cannot do this without donations. You can make a donation at http://python.org/psf/donations.html . Every penny helps so even a small donation (you can donate through PayPal or by check) helps. .. _python-dev: http://www.python.org/dev/ .. _SourceForge: http://sourceforge.net/tracker/?group_id=5470 .. _python-dev mailing list: http://mail.python.org/mailman/listinfo/python-dev .. _comp.lang.python: http://groups.google.com/groups?q=comp.lang.python .. _Docutils: http://docutils.sf.net/ .. _reST: .. _reStructuredText: http://docutils.sf.net/rst.html .. _PSF: .. _Python Software Foundation: http://python.org/psf/ .. contents:: .. _last summary: http://www.python.org/dev/summary/2004-10-01_2004-10-15.html .. _original text file: http://www.python.org/dev/summary/2004-10-16_2004-10-31.ht = Summary Announcements = `Python 2.4`_ final is now out! As I mentioned in the last summary my school schedule this past quarter has been insane. But now I am on Winter Break and will hopefully be able to catch up on my Summary backlog. .. _Python 2.4: http://www.python.org/2.4/ = Summaries = Specifying main functions and calling packages with '-m' In my opinion, the new '-m' command line option in Python 2.4 is really handy. But wouldn't it be even handier if you could execute modules in a package? That exact question came up. The reason this kind of thing didn't just go directly into 2.4 was that the semantics are not as obvious nor is it as simple. `PEP 338`_ goes over all of this and also points to a recipe that implements it all now. This also brought up the discussion of being able to specify a 'main' function to take the place of the good old ``if __name__ == "__main__"`` idiom. Some liked the idea of allowing one to define a function named 'main', others '__main__'. `PEP 299`_ discusses all of this. .. _PEP 299: http://www.python.org/peps/pep-0299.html .. _PEP 338: http://www.python.org/peps/pep-0338.html Contributing threads: - `python-dev Summary for 2004-09-16 through 2004-09-30 [draft] <http://mail.python.org/pipermail/python-dev/2004-October/049406.html>`__ - `Magic main functions <http://mail.python.org/pipermail/python-dev/2004-October/049419.html>`__ - `Supporting packages on the command line <http://mail.python.org/pipermail/python-dev/2004-October/049418.html>`__ ConfigPar
python-dev Summary for 2004-11-16 through 2004-11-30
python-dev Summary for 2004-11-16 through 2004-11-30 This is a summary of traffic on the `python-dev mailing list`_ from November 16, 2004 through November 30, 2004. It is intended to inform the wider Python community of on-going developments on the list. To comment on anything mentioned here, just post to `comp.lang.python`_ (or email python-list@python.org which is a gateway to the newsgroup) with a subject line mentioning what you are discussing. All python-dev members are interested in seeing ideas discussed by the community, so don't hesitate to take a stance on something. And if all of this really interests you then get involved and join `python-dev`_! This is the fifty-third summary written by Brett Cannon (Another quarter begins). To contact me, please send email to brett at python.org ; I do not have the time to keep up on comp.lang.python and thus do not always catch follow-ups posted there. All summaries are archived at http://www.python.org/dev/summary/ . Please note that this summary is written using reStructuredText_ which can be found at http://docutils.sf.net/rst.html . Any unfamiliar punctuation is probably markup for reST_ (otherwise it is probably regular expression syntax or a typo =); you can safely ignore it, although I suggest learning reST; it's simple and is accepted for `PEP markup`_ and gives some perks for the HTML output. Also, because of the wonders of programs that like to reformat text, I cannot guarantee you will be able to run the text version of this summary through Docutils_ as-is unless it is from the `original text file`_. .. _PEP Markup: http://www.python.org/peps/pep-0012.html The in-development version of the documentation for Python can be found at http://www.python.org/dev/doc/devel/ and should be used when looking up any documentation on new code; otherwise use the current documentation as found at http://docs.python.org/ . PEPs (Python Enhancement Proposals) are located at http://www.python.org/peps/ . To view files in the Python CVS online, go to http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/ . Reported bugs and suggested patches can be found at the SourceForge_ project page. The `Python Software Foundation`_ is the non-profit organization that holds the intellectual property for Python. It also tries to forward the development and use of Python. But the PSF_ cannot do this without donations. You can make a donation at http://python.org/psf/donations.html . Every penny helps so even a small donation (you can donate through PayPal or by check) helps. .. _python-dev: http://www.python.org/dev/ .. _SourceForge: http://sourceforge.net/tracker/?group_id=5470 .. _python-dev mailing list: http://mail.python.org/mailman/listinfo/python-dev .. _comp.lang.python: http://groups.google.com/groups?q=comp.lang.python .. _Docutils: http://docutils.sf.net/ .. _reST: .. _reStructuredText: http://docutils.sf.net/rst.html .. _PSF: .. _Python Software Foundation: http://python.org/psf/ .. contents:: .. _last summary: http://www.python.org/dev/summary/2004-11-01_2004-11-15.html .. _original text file: http://www.python.org/dev/summary/2004-11-16_2004-11-30.ht = Summary Announcements = PyCon_ is coming up! Being held March 23-25 in Washington, DC, registration is now open at http://www.python.org/pycon/2005/register.html for credit card users (you can pay by check as well; see the general info page for the conference). .. _PyCon: http://www.python.org/pycon/2005/ = Summaries = - Would you like the source with your function? - Would you like all functions and classes to contain a __pycode__ attribute that contains a string of the code used to compile that code object? Well, that very idea was proposed. You would use a command-line switch to turn on the feature in order to remove the memory and any performance overhead for the default case of not needing this feature. Some might ask why this is needed when inspect.getsource and its ilk exist. The perk is that __pycode__ would always exist while inspect.getsource is a best attempt but cannot guarantee it will have the source. Beyond a suggested name change to __source__, various people have suggested very different uses. Some see it as a convenient way to save interpreter work easily and thus not lose any nice code snippet developed interactively. Others see a more programmatic use (such as AOP "advice" injection). Both are rather different and led to the thread ending on the suggestion that a PEP be written that specifies what the intended use-case to make sure that need is properly met. Contributing threads: - `__pycode__ extension <http://mail.python.org/pipermail/python-dev/2004-November/049953.html>`__ === Skipped Threads
python-dev Summary for 2004-12-01 through 2004-12-15
This is a summary of traffic on the `python-dev mailing list`_ from December 01, 2004 through December 15, 2004. It is intended to inform the wider Python community of on-going developments on the list. To comment on anything mentioned here, just post to `comp.lang.python`_ (or email python-list@python.org which is a gateway to the newsgroup) with a subject line mentioning what you are discussing. All python-dev members are interested in seeing ideas discussed by the community, so don't hesitate to take a stance on something. And if all of this really interests you then get involved and join `python-dev`_! This is the fifty-fourth summary written by Brett Cannon (amazed no one has complained about the lateness of these summaries!). To contact me, please send email to brett at python.org ; I do not have the time to keep up on comp.lang.python and thus do not always catch follow-ups posted there. All summaries are archived at http://www.python.org/dev/summary/ . Please note that this summary is written using reStructuredText_ which can be found at http://docutils.sf.net/rst.html . Any unfamiliar punctuation is probably markup for reST_ (otherwise it is probably regular expression syntax or a typo =); you can safely ignore it, although I suggest learning reST; it's simple and is accepted for `PEP markup`_ and gives some perks for the HTML output. Also, because of the wonders of programs that like to reformat text, I cannot guarantee you will be able to run the text version of this summary through Docutils_ as-is unless it is from the `original text file`_. .. _PEP Markup: http://www.python.org/peps/pep-0012.html The in-development version of the documentation for Python can be found at http://www.python.org/dev/doc/devel/ and should be used when looking up any documentation on new code; otherwise use the current documentation as found at http://docs.python.org/ . PEPs (Python Enhancement Proposals) are located at http://www.python.org/peps/ . To view files in the Python CVS online, go to http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/ . Reported bugs and suggested patches can be found at the SourceForge_ project page. The `Python Software Foundation`_ is the non-profit organization that holds the intellectual property for Python. It also tries to forward the development and use of Python. But the PSF_ cannot do this without donations. You can make a donation at http://python.org/psf/donations.html . Every penny helps so even a small donation (you can donate through PayPal or by check) helps. .. _python-dev: http://www.python.org/dev/ .. _SourceForge: http://sourceforge.net/tracker/?group_id=5470 .. _python-dev mailing list: http://mail.python.org/mailman/listinfo/python-dev .. _comp.lang.python: http://groups.google.com/groups?q=comp.lang.python .. _Docutils: http://docutils.sf.net/ .. _reST: .. _reStructuredText: http://docutils.sf.net/rst.html .. _PSF: .. _Python Software Foundation: http://python.org/psf/ .. contents:: .. _last summary: http://www.python.org/dev/summary/2004-11-16_2004-11-30.html .. _original text file: http://www.python.org/dev/summary/2004-12-01_2004-12-15.ht = Summary Announcements = PyCon_ 2005 planning is well underway. The schedule has been posted at http://www.python.org/pycon/2005/schedule.html and looks great with a quite the varied topics. And there is still time for the early-bird registration price of $175 ($125 students) before it expires on January 28th. Some day I will be all caught up with the Summaries... .. _PyCon: http://www.pycon.org = Summaries = -- PEPS: those existing and gestating -- [for emails on PEP updates, subscribe to python-checkins_ and choose the 'PEP' topic] A proto-PEP covering the __source__ proposal from the `last summary`_ has been posted to python-dev. `PEP 338`_ proposes how to modify the '-m' modifier so as to be able to execute modules contained within packages. .. _python-checkins: http://mail.python.org/mailman/listinfo/python-checkins .. _PEP 338: http://www.python.org/peps/pep-0338.html Contributing threads: - `PEP: __source__ proposal <http://mail.python.org/pipermail/python-dev/2004-December/050190.html>`__ - `PEP 338: Executing modules inside packages with '-m' <http://mail.python.org/pipermail/python-dev/2004-December/050369.html>`__ --- Deprecating modules --- The xmllib module was deprecated but not listed in `PEP 4`_. What does one do? Well, this led to a long discussion on how to handle module deprecation. With the 'warning' module now in existence, PEP 4 seemed to be less important. It was generally agreed that listing modules in PEP 4 was no longer needed. It was also agreed that deleting deprecated modules was not needed; it breaks code and disk
python-dev Summary for 2004-12-16 through 2004-12-31
This is a summary of traffic on the `python-dev mailing list`_ from December 16, 2004 through December 31, 2004. It is intended to inform the wider Python community of on-going developments on the list. To comment on anything mentioned here, just post to `comp.lang.python`_ (or email python-list@python.org which is a gateway to the newsgroup) with a subject line mentioning what you are discussing. All python-dev members are interested in seeing ideas discussed by the community, so don't hesitate to take a stance on something. And if all of this really interests you then get involved and join `python-dev`_! This is the fifty-fifth summary written by Brett Cannon (I have been doing this for too long...). To contact me, please send email to brett at python.org ; I do not have the time to keep up on comp.lang.python and thus do not always catch follow-ups posted there. All summaries are archived at http://www.python.org/dev/summary/ . Please note that this summary is written using reStructuredText_ which can be found at http://docutils.sf.net/rst.html . Any unfamiliar punctuation is probably markup for reST_ (otherwise it is probably regular expression syntax or a typo =); you can safely ignore it, although I suggest learning reST; it's simple and is accepted for `PEP markup`_ and gives some perks for the HTML output. Also, because of the wonders of programs that like to reformat text, I cannot guarantee you will be able to run the text version of this summary through Docutils_ as-is unless it is from the `original text file`_. .. _PEP Markup: http://www.python.org/peps/pep-0012.html The in-development version of the documentation for Python can be found at http://www.python.org/dev/doc/devel/ and should be used when looking up any documentation on new code; otherwise use the current documentation as found at http://docs.python.org/ . PEPs (Python Enhancement Proposals) are located at http://www.python.org/peps/ . To view files in the Python CVS online, go to http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/ . Reported bugs and suggested patches can be found at the SourceForge_ project page. The `Python Software Foundation`_ is the non-profit organization that holds the intellectual property for Python. It also tries to forward the development and use of Python. But the PSF_ cannot do this without donations. You can make a donation at http://python.org/psf/donations.html . Every penny helps so even a small donation (you can donate through PayPal or by check) helps. .. _python-dev: http://www.python.org/dev/ .. _SourceForge: http://sourceforge.net/tracker/?group_id=5470 .. _python-dev mailing list: http://mail.python.org/mailman/listinfo/python-dev .. _comp.lang.python: http://groups.google.com/groups?q=comp.lang.python .. _Docutils: http://docutils.sf.net/ .. _reST: .. _reStructuredText: http://docutils.sf.net/rst.html .. _PSF: .. _Python Software Foundation: http://python.org/psf/ .. contents:: .. _last summary: http://www.python.org/dev/summary/2004-12-01_2004-12-15.html .. _original text file: http://www.python.org/dev/summary/2004-12-16_2004-12-31.ht = Summary Announcements = You can still `register <http://www.python.org/pycon/2005/register.html>`__ for `PyCon`_. The `schedule of talks`_ is now online. Jim Hugunin is lined up to be the keynote speaker on the first day with Guido being the keynote on Thursday. Once again PyCon looks like it is going to be great. On a different note, as I am sure you are all aware I am still about a month behind in summaries. School this quarter for me has just turned out hectic. I think it is lack of motivation thanks to having finished my 14 doctoral applications just a little over a week ago (and no, that number is not a typo). I am going to for the first time in my life come up with a very regimented study schedule that will hopefully allow me to fit in weekly Python time so as to allow me to catch up on summaries. And this summary is not short because I wanted to finish it. 2.4 was released just before the time this summary covers so most stuff was on bug fixes discovered after the release. .. _PyCon: http://www.pycon.org/ .. _schedule of talks: http://www.python.org/pycon/2005/schedule.html === Summary === - PEP movements - I introduced a `proto-PEP <http://mail.python.org/pipermail/python-dev/2005-January/050753.html>`__ to the list on how one can go about changing CPython's bytecode. It will need rewriting once the AST branch is merged into HEAD on CVS. Plus I need to get a PEP number assigned to me. =) Contributing threads: - `proto-pep: How to change Python's bytecode <http://mail.python.org/pipermail/python-dev/2004-December/050542.html>`__ Handling versioning within a package The suggestion of exten
Better console for Windows?
This is a pretty basic, mostly un-python-related question, although I'm asking because of Python. Is there a different shell I can use (other than cmd.com) to run Python in, where I can full-screen the window (if I pleased), etc? As it is, things that would run far off the right have to be word wrapped after very few characters. Another problem with cmd.com is when I run IPython, if I have an error, or tab or anything, I get the speaker beep (ala linux) but I can't find a way to turn it off. This is a huge problem because I cannot disable my system speaker on my laptop (not even in BIOS like my old one, and it's an "error", it bypasses the fact that all my sound is muted in Windows) and I get incredibly loud beeps all the time (because I suck) which would not be acceptable while I'm coding on the sly in boring class. Ideas? The only thing I can think of now is using Putty to SSH into a machine, no beeps there, and I can resize... but I don't have a machine to SSH into, much less one with all the stuff I want on it. Thanks in advance. Brett -- http://mail.python.org/mailman/listinfo/python-list
Re: Better console for Windows?
Rune Strand wrote: > I know that problem... it's extremely annoying! > Here's one way to solve it; > > 1. Start 'Device manager'. > 2. On the menu, click 'View' and check off "Show hidden devices" > 3. Locate 'Beep' 'under Non-Plug and Play Drivers' > 4. Right-click 'Beep', select 'Disable' Christ, thanks. When you install Windows it should pop up first thing and ask if you want to be annoyed, Y/N. Well, that solves my sound problem (thanks again), now if only I could stretch the window horizontally. Thats much less of a problem though, this is at least usable now. Thanks again, Rune -- http://mail.python.org/mailman/listinfo/python-list
Re: Better console for Windows?
Benji York wrote: > To make the console full screen hit Alt-Enter. The same thing makes it > windowed again. To accommodate very long lines click the "C:\" icon in > the upper left corner of the window, choose "Properties" and then change > the "Screen Buffer Size" Width and Height to something more to your liking. > > While you're there I'd recommend turning on "QuickEdit Mode" on the > "Options" tab. Then you can drag with your left mouse button to select > an area of text, right click to copy, then right click again to paste. Thanks very much, not sure why I always missed those. I guess I was just frustrated in general. This will make python a lot more enjoyable. Brett -- http://mail.python.org/mailman/listinfo/python-list
Re: Better console for Windows?
Philippe C. Martin wrote: > You might want to check out ipyhton. I use it. :) I love it. When I meant console I meant the shell app that runs any text-based programs. The windows console was giving me loud beeps, etc, which I've now fixed. Thanks for your reply though, Brett -- http://mail.python.org/mailman/listinfo/python-list
Re: [Python-Dev] python optimization
On 9/15/05, Neal Becker <[EMAIL PROTECTED]> wrote: > I use cpython. I'm accustomed (from c++/gcc) to a style of coding that is > highly readable, making the assumption that the compiler will do good > things to optimize the code despite the style in which it's written. For > example, I assume constants are removed from loops. In general, an entity > is defined as close to the point of usage as possible. > > I don't know to what extent these kind of optimizations are available to > cpython. For example, are constant calculations removed from loops? If you mean ``2+3``, then yes. If you mean ``2 + a`` where is a loop invariant, then no. > How > about functions? No optimization there. > Is there a significant cost to putting a function def > inside a loop rather than outside? > If you put it in a loop then the function must be reconstructed every time through the loop. I have never benchmarked the cost of function construction but I doubt it's cheap. The problem with all of these optimizations that you can do in more static languages is you get to assume most things do not change from underneath you. In Python, thanks to threading, access to frames, global namespaces of modules, etc., most things cannot be naively optimized without a lot of checking up front to make sure the optimization is valid every time it is run. If you want some gruesome detail, you can read my thesis (http://www.drifty.org/thesis.pdf) and the section on problems with introducing type inference into Python. -Brett -- http://mail.python.org/mailman/listinfo/python-list
Re: How am I doing?
Wouldn't the standard idiom be to actually put the code under the if-name, and not make a whole new main() function? I'm not sure I see the reason behind main(), couldn't that also interfere with other modules since main() seems like it might be common, not sure how it would work as I'm pretty new to Python myself. from script import * ... what happens when you have two main()s? -- http://mail.python.org/mailman/listinfo/python-list
Re: Calling python scripts from C# programs
David Wilson wrote: > http://www.ironpython.com/ It should be noted that they (?) don't seem to update that site anymore, you can find 0.9.1 here: http://workspaces.gotdotnet.com/ironpython There is also Boo, which is Python-like (with some differences) but is a .NET Language itself. I never understood if IronPython was ment to be fully Python compatible, so I don't know if Boo is the same or further from what you may want... anyways, http://boo.codehaus.org/ -- http://mail.python.org/mailman/listinfo/python-list
python-dev Summary for 2005-01-01 through 2005-01-15
This is a summary of traffic on the `python-dev mailing list`_ from January 01, 2005 through January 15, 2005. It is intended to inform the wider Python community of on-going developments on the list. To comment on anything mentioned here, just post to `comp.lang.python`_ (or email python-list@python.org which is a gateway to the newsgroup) with a subject line mentioning what you are discussing. All python-dev members are interested in seeing ideas discussed by the community, so don't hesitate to take a stance on something. And if all of this really interests you then get involved and join `python-dev`_! This is the fifty-sixth summary written by Brett Cannon (I don't want to do my homework). To contact me, please send email to brett at python.org ; I do not have the time to keep up on comp.lang.python and thus do not always catch follow-ups posted there. All summaries are archived at http://www.python.org/dev/summary/ . Please note that this summary is written using reStructuredText_ which can be found at http://docutils.sf.net/rst.html . Any unfamiliar punctuation is probably markup for reST_ (otherwise it is probably regular expression syntax or a typo =); you can safely ignore it, although I suggest learning reST; it's simple and is accepted for `PEP markup`_ and gives some perks for the HTML output. Also, because of the wonders of programs that like to reformat text, I cannot guarantee you will be able to run the text version of this summary through Docutils_ as-is unless it is from the `original text file`_. .. _PEP Markup: http://www.python.org/peps/pep-0012.html The in-development version of the documentation for Python can be found at http://www.python.org/dev/doc/devel/ and should be used when looking up any documentation on new code; otherwise use the current documentation as found at http://docs.python.org/ . PEPs (Python Enhancement Proposals) are located at http://www.python.org/peps/ . To view files in the Python CVS online, go to http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/ . Reported bugs and suggested patches can be found at the SourceForge_ project page. The `Python Software Foundation`_ is the non-profit organization that holds the intellectual property for Python. It also tries to forward the development and use of Python. But the PSF_ cannot do this without donations. You can make a donation at http://python.org/psf/donations.html . Every penny helps so even a small donation (you can donate through PayPal or by check) helps. .. _python-dev: http://www.python.org/dev/ .. _SourceForge: http://sourceforge.net/tracker/?group_id=5470 .. _python-dev mailing list: http://mail.python.org/mailman/listinfo/python-dev .. _comp.lang.python: http://groups.google.com/groups?q=comp.lang.python .. _Docutils: http://docutils.sf.net/ .. _reST: .. _reStructuredText: http://docutils.sf.net/rst.html .. _PSF: .. _Python Software Foundation: http://python.org/psf/ .. contents:: .. _last summary: http://www.python.org/dev/summary/2004-12-16_2004-12-31.html .. _original text file: http://www.python.org/dev/summary/2005-01-01_2005-01-15.ht = Summary Announcements = PyCon_ will be upon us come late March! Still time to plan to go. A warning on the thoroughness off this summary is in order. While trying to delete a single thread of email I managed to accidentally delete my entire python-dev mailbox. I did the best I could to retrieve the emails but it's possible I didn't resuscitate all of my emails, so I may have overlooked something. .. _PyCon: http://www.pycon.org/ === Summary === - PEP movements - tip:: PEP updates by email are available as a topic from the `Python-checkins`_ mailing list. `PEP 246`_ was a major topic of discussion during the time period covered by this summary. This all stemmed from `Guido's blog`_ entries on optional type checking. This led to a huge discussion on many aspects of protocols, interfaces, and adaptation and the broadening of this author's vocabulary to include "Liskov violation". "Monkey typing" also became a new term to know thanks to Phillip J. Eby's proto-PEP on the topic (found at http://peak.telecommunity.com/DevCenter/MonkeyTyping). Stemming from the phrase "monkey see, monkey do", it's Phillip version of taking PEP 246 logically farther (I think; the whole thing is more than my currently burned-out-on-school brain can handle right now). .. _Python-checkins: http://mail.python.org/mailman/listinfo/python-checkins .. _PEP 246: http://www.python.org/peps/pep-0246.html .. _Guido's blog: http://www.artima.com/weblogs/index.jsp?blogger=guido Contributing threads: - `getattr and __mro__ <http://mail.python.org/pipermail/python-dev/2005-January/050907.html>`__ - `Son of PEP 246, redux <http://mail.python.org/pipermail/python-dev/2
python-dev Summary for 2005-01-16 through 2005-01-31
eveloped.
Guido said it would be piece-meal. Read
http://joelonsoftware.com/articles/fog69.html for why.
Contributing threads:
- `Speed up function calls
<http://mail.python.org/pipermail/python-dev/2005-January/051251.html>`__
- `Moving towards Python 3.0
<http://mail.python.org/pipermail/python-dev/2005-January/051355.html>`__
How to handle memory allocation with the presence of threads
Evan Jones has been working on a patch to allow the garbage collector to free
up memory of small objects. This led him to ask questions in terms of memory
usage in the face of threading at the C level. While the GIL usually needs to
be held for any operation that touches Python code, he was not sure if this
held for the memory API.
Tim Peters clarified all of this by pointing out the documentation in the C API
manual about the GIL. In a nutshell the memory API is not exempt from needing
to hold the GIL, so hold it.
It was also pointed out there was a bunch of code to allow people to mix usage
of PyMem_* functions with PyObject_* functions. That was purely done for
backwards-compatibility back in the day. Mixing these two APIs for memory is
very bad. Don't do it!
Contributing threads:
- `Improving the Python Memory Allocator
<http://mail.python.org/pipermail/python-dev/2005-January/051255.html>`__
- `Python Interpreter Thread Safety?
<http://mail.python.org/pipermail/python-dev/2005-January/051335.html>`__
--
Slicing iterators rejected
--
Nick Coghlan proposed allowing iterators to be sliced liked other sequence
types. That way something like ``enumerate("ABCD")[1:]`` would work.
But Guido rejected it. With itertools.islice existence it does not provide new
functionality. Plus "Iterators are for single sequential access" according to
Guido, and thus should not be confused with sequences.
Contributing threads:
- `Allowing slicing of iterators
<http://mail.python.org/pipermail/python-dev/2005-January/051257.html>`__
===
Skipped Threads
===
- redux: fractional seconds in strptime
- how to test behavior wrt an extension type?
- Strange segfault in Python threads and linux kernel 2.6
- Unix line endings required for PyRun* breaking embedded Python
- Zen of Python
- PyCon: The Spam Continues ;-)
- Patch review: [ 1094542 ] add Bunch type to collections module
Epilogue
Introduction
This is a summary of traffic on the `python-dev mailing list`_ from
January 16, 2005 through January 31, 2005.
It is intended to inform the wider Python community of on-going
developments on the list on a semi-monthly basis. An archive_ of
previous summaries is available online.
An `RSS feed`_ of the titles of the summaries is available.
You can also watch comp.lang.python or comp.lang.python.announce for
new summaries (or through their email gateways of python-list or
python-announce, respectively, as found at http://mail.python.org).
This is the fifty-seventh summary written by Brett Cannon (grad schools are
actually crazy enough to accept me =).
To contact me, please send email to brett at python.org. Do *not*
post to comp.lang.python if you wish to reach me.
The `Python Software Foundation`_ is the non-profit organization that
holds the intellectual property for Python. It also tries to advance
the development and use of Python. If you find the python-dev Summary
helpful please consider making a donation. You can make a donation at
http://python.org/psf/donations.html . Every penny helps so even a
small donation with a credit card, check, or by PayPal helps.
If you are looking for a way to expand your knowledge of Python's
development and inner-workings, consider writing the python-dev
Summaries yourself! I am willing to hand over the reins to someone
who is willing to do a comparable or better job of writing the
Summaries. If you are interested, please email me at
brett at python.org.
Commenting on Topics
To comment on anything mentioned here, just post to
`comp.lang.python`_ (or email python-list@python.org which is a
gateway to the newsgroup) with a subject line mentioning what you are
discussing. All python-dev members are interested in seeing ideas
discussed by the community, so don't hesitate to take a stance on
something. And if all of this really interests you then get involved
and join `python-dev`_!
-
How to Read the Summaries
-
The in-development version of the documentation for Python can be
found at http://www.python.org/dev/doc/devel/ and should be used when
looking up any documentation for new code; otherwise use the current
documentation as found at http://docs.python.org/ . P
OK, time to retire (was: Re: python-dev Summary for 2005-01-16 through 2005-01-31)
Steve Holden wrote: Michele Simionato wrote [on c.l.py]: Brett Cannon: [... python-dev summary ... boilerplate change ...] +1 for this idea. The summary looks much better now :) Keep the good work going, Sorry, but i have to disagree. I hope you won't take this reply personally, Michele, since it's directed to all c.l.py readers, as well as (particularly) at Python users who [unlike you] are mostly take and rather less give. Although this is inherently the nature of open source, in certain cases this can be taken too far. [SNIP] Now, the reason for this specific rant is this: I can tell a cry for help when I see one. Brett has done a magnificent job of providing python-dev summaries since Andrew decided he'd had enough, and he is to be congratulated for it. I managed to offload another bunch of work on him (moderation of various troublesome PyCon mailing lists), but at least I was able to recompense him by letting him into PyCon for nothing. [SNIP] But frankly, I think it's time someone else stood up and said "Brett, you've done a magnificent job. Hesitant though I am about replacing you, I would like to volunteer for the task, because only when you are free from the burden of writing the python-dev summaries will we see what else you are capable of". Since I am at best an intermittent reader of python-dev I can say this without fear of having to stand up myself. [SNIP] [I am going to use this to reply to both Steve and Martin] As Steve mentioned above, he can spot a cry for help when he sees one. I think the problem is that I am a total sucker when it comes to the Python community and python-dev. Anyone who has been on the python-dev list for as long as I have been a participant has most likely seen my almost yearly "thank you" emails I send the list (which there will probably be another one of once I choose where I am going to pursue my doctorate; I have acceptances but I am still waiting to here back from 9 more schools). Usually it is just me gushing to python-dev, thanking the list for how Python has gotten me where I am today. And that statement is completely sincere; python-dev has sculpted me into the programmer that I am (does this mean I can blame python-dev for my own buggy code? =). And for that I will be eternally grateful to all of the wonderful people I have gotten to work with and know on this list. It has also made me want to help people to get involved on python-dev in hopes others would benefit from python-dev the same way I have. Granted, python-dev tends not to attract people like I was when I started getting involved (a philosophy degree and 4 CS courses does not equal a good programmer by default =), but I have always hoped that through my efforts some other people could come to enjoy hacking on Python, learn some things, and advance the language. But I think the big problem is that the Summaries have become a "gift" in the truest sense of the word. I lost all personal benefit from the Summaries over a year ago. Initially I learned a ton from all of the reading I was doing and the research required to understand what the heck people were talking about. But I have graduated from "The School of Hard Knocks". At this point I do the Summaries entirely altruistically, giving back what I can to the community in a way that I know benefits many people which happens to have zero benefit to me now. The Summaries consume what little free time I do have for Python which is unfortunate. I have always hoped I would get to the point in my programming abilities that I would be a larger asset to python-dev as a programmer than as a writer. I would like to think I have reached that point finally after my over two and a half years on the list (I can't believe I first posted to the list on June 17, 2002!). So, to make sure I don't squander what time I do have for Python waiting for a possible replacement that might never come, I have decided that I am going to stop doing the python-dev Summaries after PyCon; the Summary covering the last half of March 2005 will be it for me. Hopefully I will be more valuable as an active participant on python-dev again instead of as a passive listener who just happens to chime in on occasion and squash a simple bug when I am procrastinating from doing my homework. This has been a long time coming and I needed a swift kick in the ass to finally get me to stop. I thank you, Steve, for giving me that kick like the English gentleman you are. =) -Brett -- http://mail.python.org/mailman/listinfo/python-list
Re: [Python-Dev] Re: OK, time to retire
[taking python-dev off of the Cc: list] Scott David Daniels wrote: Brett C. wrote: I have decided that I am going to stop doing the python-dev Summaries > after PyCon; the Summary covering the last half of March 2005 will be > it for me. I (as well as most, I'd guess) have enjoyed your voice in the summaries. Thanks for a great series of summaries. Perhaps your final summary could be a personal view of PyCon for those of us unable to get there. If people want that, sure, be happy to cover PyCon. Anybody else like that idea? Or do the various bloggers who attend do a good enough job of coverage? If you make no more contribution to Python than you have so far, you will have done us a great service. =) Thanks. Glad I have been able to help. -Brett -- http://mail.python.org/mailman/listinfo/python-list
python-dev Summary for 2005-02-01 through 2005-02-14
hat builtin_id() can return a negative number in Python 2.4 (and can generate a warning in 2.3). Some 2.3 modules (but no 2.4 ones) have code to work around this, but Troels suggested that a better solution would be to simply have builtin_id() return an unsigned long integer. The consensus was that this would be a good idea, although nothing has been checked in yet, and so this will probably stagnate without someone submitting a patch (or at least a bug report). Contributing threads: - `builtin_id() returns negative numbers <http://mail.python.org/pipermail/python-dev/2005-February/051559.html>`__ === Skipped Threads === + Son of PEP 246, redux + Re: PEP 246: LiskovViolation as a name + Re: [Python-checkins] python/dist/src/Python future.c, 2.14, 2.15 + Other library updates + Re: python/dist/src/Lib rfc822.py,1.78,1.79 + Patch review: [ 1098732 ] Enhance tracebacks and stack traces with vars + Re: [Python-checkins] python/dist/src/Python compile.c, 2.343, 2.344 + Re: [Python-checkins] python/dist/src/Lib xmlrpclib.py, 1.38, 1.39 + ViewCVS on SourceForge is broken Epilogue Introduction This is a summary of traffic on the `python-dev mailing list`_ from February 01, 2005 through February 14, 2005. It is intended to inform the wider Python community of on-going developments on the list on a semi-monthly basis. An archive_ of previous summaries is available online. An `RSS feed`_ of the titles of the summaries is available. You can also watch comp.lang.python or comp.lang.python.announce for new summaries (or through their email gateways of python-list or python-announce, respectively, as found at http://mail.python.org). This is the fifty-eighth summary written by Brett Cannon (3 more after this one). To contact me, please send email to brett at python.org. Do *not* post to comp.lang.python if you wish to reach me. The `Python Software Foundation`_ is the non-profit organization that holds the intellectual property for Python. It also tries to advance the development and use of Python. If you find the python-dev Summary helpful please consider making a donation. You can make a donation at http://python.org/psf/donations.html . Every penny helps so even a small donation with a credit card, check, or by PayPal helps. If you are looking for a way to expand your knowledge of Python's development and inner-workings, consider writing the python-dev Summaries yourself! I am willing to hand over the reins to someone who is willing to do a comparable or better job of writing the Summaries. If you are interested, please email me at brett at python.org. Commenting on Topics To comment on anything mentioned here, just post to `comp.lang.python`_ (or email python-list@python.org which is a gateway to the newsgroup) with a subject line mentioning what you are discussing. All python-dev members are interested in seeing ideas discussed by the community, so don't hesitate to take a stance on something. And if all of this really interests you then get involved and join `python-dev`_! - How to Read the Summaries - The in-development version of the documentation for Python can be found at http://www.python.org/dev/doc/devel/ and should be used when looking up any documentation for new code; otherwise use the current documentation as found at http://docs.python.org/ . PEPs (Python Enhancement Proposals) are located at http://www.python.org/peps/ . To view files in the Python CVS online, go to http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/ . Reported bugs and suggested patches can be found at the SourceForge_ project page. Please note that this summary is written using reStructuredText_. Any unfamiliar punctuation is probably markup for reST_ (otherwise it is probably regular expression syntax or a typo =); you can safely ignore it. I do suggest learning reST, though; it's simple and is accepted for `PEP markup`_ and can be turned into many different formats like HTML and LaTeX. Unfortunately, even though reST is standardized, the wonders of programs that like to reformat text do not allow me to guarantee you will be able to run the text version of this summary through Docutils_ as-is unless it is from the `original text file`_. .. _python-dev: http://www.python.org/dev/ .. _SourceForge: http://sourceforge.net/tracker/?group_id=5470 .. _python-dev mailing list: http://mail.python.org/mailman/listinfo/python-dev .. _c.l.py: .. _comp.lang.python: http://groups.google.com/groups?q=comp.lang.python .. _PEP Markup: http://www.python.org/peps/pep-0012.html .. _Docutils: http://docutils.sf.net/ .. _reST: .. _reStructuredText: http://docutils.sf.net/rst.html .. _PSF: .. _Python Software Foundation: http://python.org/psf/ .. _last summary: http://www.python.org/dev/summary/2005-01-16_2005-01-31.html .. _original text file: http://www.python.org/dev/summary/2005-02-01_2005-02-14.ht .. _archive: http://www.python.org/dev/summary/ .. _RSS feed: http://www.python.org/dev/summary/channews.rdf -- http://mail.python.org/mailman/listinfo/python-list
python-dev Summary for 2005-02-15 through 2005-02-28
little benefit. Off this a discussion about speeding up frame allocation, an area viewed as needing some optimization, started up. Contributing threads: - `Store x Load x --> DupStore <http://mail.python.org/pipermail/python-dev/2005-February/051716.html>`__ --- Slow unit tests should be distinguished --- note:: written by Tony Meyer Guido clarified that unit tests should distinguish between "regular" tests and slow ones by use of the unit test 'resource' keys, as a result of Peter Ãstrand asking for comments about `bug #1124637`_, which complained that test_subprocess is too slow. The suggested solution was to add another resource for subprocess, so that generally a quick version would run, but a longer, more thorough test would run with -uall or -usubprocess. Along the way, it was discovered that the reason that Windows already ran test_subprocess quickly was because there was code special-casing it to be fast. The resource solution was checked in, although Windows was left special-cased. .. _bug #1124637: http://www.python.org/sf/1124637 Contributing threads: - `[ python-Bugs-1124637 ] test_subprocess is far too slow (fwd) <http://mail.python.org/pipermail/python-dev/2005-February/051618.html>`__ --- Clarification of the '5 for 1' deal --- note:: written by Tony Meyer It seems that the offer that some python-dev'ers have made to review a patch in exchange for reviews of five (originally ten) other patches is finally being taken up by various people. However, python-dev traffic has increased with patch and bug reviews, and the question was posed whether reviews should be posted in general, or only for this specific deal. The answer is that the comments should also be entered via the SourceForge tracking system, but that a brief message covering a bunch (rather than individual) of reviews is acceptable for python-dev, at least for now. New reports should almost never be posted to python-dev, however, and should be entered via the tracking system. This offer isn't official policy, but a reference to it will be added to Brett's summary of the development process. However, people should also remember that it may take developers some time to find time to deal with reviews, and so have patience after posting their review. Contributing threads: - `discourage patch reviews to the list? <http://mail.python.org/pipermail/python-dev/2005-February/051475.html>`__ - `Some old patches <http://mail.python.org/pipermail/python-dev/2005-February/051705.html>`__ - `Five review rule on the /dev/ page? <http://mail.python.org/pipermail/python-dev/2005-February/051633.html>`__ === Skipped Threads === + pymalloc on 2.1.3 + Exceptions *must*? be old-style classes? + subclassing PyCFunction_Type + Windows Low Fragementation Heap yields speedup of ~15% + string find(substring) vs. substring in string + Some old patches + Comment regarding PEP 328 Epilogue Introduction This is a summary of traffic on the `python-dev mailing list`_ from February 15, 2005 through February 28, 2005. It is intended to inform the wider Python community of on-going developments on the list on a semi-monthly basis. An archive_ of previous summaries is available online. An `RSS feed`_ of the titles of the summaries is available. You can also watch comp.lang.python or comp.lang.python.announce for new summaries (or through their email gateways of python-list or python-announce, respectively, as found at http://mail.python.org). This is the fifty-nineth summary written by Brett Cannon (two more to go!). To contact me, please send email to brett at python.org. Do *not* post to comp.lang.python if you wish to reach me. The `Python Software Foundation`_ is the non-profit organization that holds the intellectual property for Python. It also tries to advance the development and use of Python. If you find the python-dev Summary helpful please consider making a donation. You can make a donation at http://python.org/psf/donations.html . Every penny helps so even a small donation with a credit card, check, or by PayPal helps. If you are looking for a way to expand your knowledge of Python's development and inner-workings, consider writing the python-dev Summaries yourself! I am willing to hand over the reins to someone who is willing to do a comparable or better job of writing the Summaries. If you are interested, please email me at brett at python.org. Commenting on Topics To comment on anything mentioned here, just post to `comp.lang.python`_ (or email python-list@python.org which is a gateway to the newsgroup) with a subject line mentioning what you are discussing. All python-dev members are interes
Ptyon 2.3.5 probably coming in January; get your bugs/patches reported!
Anthony Baxter, our ever-diligent release manager, mentioned this past week that Python 2.3.5 will most likely come to fruition some time in January (this is not guaranteed date). This means that in order to have enough time to proper evaluate new patches and bugs they must be reported **now**! A one month lead time is necessary to properly look at, test, and commit patches, let alone coming up with solutions to any reported bugs. Please realize, though, that reporting a bug or submitting a patch now does not guarantee that it will committed in time! The free time of the development team is limited. If you want to help a bug or patch along to make it easier to be evaluated and thus raise its chances of being dealt with please see the "Helping Out" section of the 'Intro to Development' essay at http://www.python.org/dev/dev_intro.html . As always, both bugs and patches should be reported to Python's SourceForge tracker at http://sourceforge.net/bugs/?group_id=5470 and http://sourceforge.net/patch/?group_id=5470, respectively. -Brett Cannon -- http://mail.python.org/mailman/listinfo/python-list
python-dev Summary for 2004-11-01 through 2004-11-15
python-dev Summary for 2004-11-01 through 2004-11-15 This is a summary of traffic on the `python-dev mailing list`_ from November 01, 2004 through November 15, 2004. It is intended to inform the wider Python community of on-going developments on the list. To comment on anything mentioned here, just post to `comp.lang.python`_ (or email python-list@python.org which is a gateway to the newsgroup) with a subject line mentioning what you are discussing. All python-dev members are interested in seeing ideas discussed by the community, so don't hesitate to take a stance on something. And if all of this really interests you then get involved and join `python-dev`_! This is the fifty-second summary written by Brett Cannon (Happy Holidays). To contact me, please send email to brett at python.org ; I do not have the time to keep up on comp.lang.python and thus do not always catch follow-ups posted there. All summaries are archived at http://www.python.org/dev/summary/ . Please note that this summary is written using reStructuredText_ which can be found at http://docutils.sf.net/rst.html . Any unfamiliar punctuation is probably markup for reST_ (otherwise it is probably regular expression syntax or a typo =); you can safely ignore it, although I suggest learning reST; it's simple and is accepted for `PEP markup`_ and gives some perks for the HTML output. Also, because of the wonders of programs that like to reformat text, I cannot guarantee you will be able to run the text version of this summary through Docutils_ as-is unless it is from the `original text file`_. .. _PEP Markup: http://www.python.org/peps/pep-0012.html The in-development version of the documentation for Python can be found at http://www.python.org/dev/doc/devel/ and should be used when looking up any documentation on new code; otherwise use the current documentation as found at http://docs.python.org/ . PEPs (Python Enhancement Proposals) are located at http://www.python.org/peps/ . To view files in the Python CVS online, go to http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/ . Reported bugs and suggested patches can be found at the SourceForge_ project page. The `Python Software Foundation`_ is the non-profit organization that holds the intellectual property for Python. It also tries to forward the development and use of Python. But the PSF_ cannot do this without donations. You can make a donation at http://python.org/psf/donations.html . Every penny helps so even a small donation (you can donate through PayPal or by check) helps. .. _python-dev: http://www.python.org/dev/ .. _SourceForge: http://sourceforge.net/tracker/?group_id=5470 .. _python-dev mailing list: http://mail.python.org/mailman/listinfo/python-dev .. _comp.lang.python: http://groups.google.com/groups?q=comp.lang.python .. _Docutils: http://docutils.sf.net/ .. _reST: .. _reStructuredText: http://docutils.sf.net/rst.html .. _PSF: .. _Python Software Foundation: http://python.org/psf/ .. contents:: .. _last summary: http://www.python.org/dev/summary/2004-10-16_2004-10-31.html .. _original text file: http://www.python.org/dev/summary/2004-11-01_2004-11-15.ht = Summary Announcements = I am hoping to be caught up with my summary backlog by the end of the month. Here is to hoping. = Summaries = 2.4 released `Python 2.4`_ has been released! Read the `What's New`_ for 2.4 to see what the major changes are since 2.3 . .. _Python 2.4: http://www.python.org/2.4/ .. _What's New: http://www.python.org/doc/2.4/whatsnew/whatsnew24.html Contributed threads: - `TRUNK FROZEN for 2.4b2 release from UTC 3rd November (tomorrrow) <http://mail.python.org/pipermail/python-dev/2004-November/049736.html>`__ - `RELEASED Python 2.4, beta 2 <http://mail.python.org/pipermail/python-dev/2004-November/049754.html>`__ - `TRUNK UNFROZEN <http://mail.python.org/pipermail/python-dev/2004-November/049762.html>`__ - Code coverage of the regression tests - Walter DÃrwald has a code coverage tool that runs once a month on Python's regression test at http://coverage.livinglogic.de/ . There was some issue with the 'trace' module having partially broken in 2.4 . The coverage was then run using ``Lib/test/regrtest.py -T`` to get more accurate numbers. Contributing threads: - `Code coverage tool updated <http://mail.python.org/pipermail/python-dev/2004-November/049727.html>`__ Garbage collecting weakref callbacks Tim Peters discovered that in 2.4 if a weakref's callback is still reachable but the referent and weakref itself are unreachable (Tim's example had an instance that contained a weakref to itse
python-dev Summary for 2005-03-01 through 2005-03-15
= + Re: python-dev Summary for 2005-01-16 through 2005-01-31 + Documentation for __new__ + Decimal & returning NotImplemented (or not) + itemgetter/attrgetter extension + Re: [Python-checkins] python/dist/src/Lib/idlelib NEWS.txt, 1.49.2.3, 1.49.2.4 idlever.py, 1.22.2.1, 1.22.2.2 + code blocks using 'for' loops and generators + can we stop pretending _PyTyple_Lookup is internal? Epilogue Introduction This is a summary of traffic on the `python-dev mailing list`_ from March 01, 2005 through March 15, 2005. It is intended to inform the wider Python community of on-going developments on the list on a semi-monthly basis. An archive_ of previous summaries is available online. An `RSS feed`_ of the titles of the summaries is available. You can also watch comp.lang.python or comp.lang.python.announce for new summaries (or through their email gateways of python-list or python-announce, respectively, as found at http://mail.python.org). This is the sixieth summary written by Brett Cannon (sprinting my Spring Break away). To contact me, please send email to brett at python.org. Do *not* post to comp.lang.python if you wish to reach me. The `Python Software Foundation`_ is the non-profit organization that holds the intellectual property for Python. It also tries to advance the development and use of Python. If you find the python-dev Summary helpful please consider making a donation. You can make a donation at http://python.org/psf/donations.html . Every penny helps so even a small donation with a credit card, check, or by PayPal helps. If you are looking for a way to expand your knowledge of Python's development and inner-workings, consider writing the python-dev Summaries yourself! I am willing to hand over the reins to someone who is willing to do a comparable or better job of writing the Summaries. If you are interested, please email me at brett at python.org. Commenting on Topics To comment on anything mentioned here, just post to `comp.lang.python`_ (or email python-list@python.org which is a gateway to the newsgroup) with a subject line mentioning what you are discussing. All python-dev members are interested in seeing ideas discussed by the community, so don't hesitate to take a stance on something. And if all of this really interests you then get involved and join `python-dev`_! - How to Read the Summaries - The in-development version of the documentation for Python can be found at http://www.python.org/dev/doc/devel/ and should be used when looking up any documentation for new code; otherwise use the current documentation as found at http://docs.python.org/ . PEPs (Python Enhancement Proposals) are located at http://www.python.org/peps/ . To view files in the Python CVS online, go to http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/ . Reported bugs and suggested patches can be found at the SourceForge_ project page. Please note that this summary is written using reStructuredText_. Any unfamiliar punctuation is probably markup for reST_ (otherwise it is probably regular expression syntax or a typo =); you can safely ignore it. I do suggest learning reST, though; it's simple and is accepted for `PEP markup`_ and can be turned into many different formats like HTML and LaTeX. Unfortunately, even though reST is standardized, the wonders of programs that like to reformat text do not allow me to guarantee you will be able to run the text version of this summary through Docutils_ as-is unless it is from the `original text file`_. .. _python-dev: http://www.python.org/dev/ .. _SourceForge: http://sourceforge.net/tracker/?group_id=5470 .. _python-dev mailing list: http://mail.python.org/mailman/listinfo/python-dev .. _c.l.py: .. _comp.lang.python: http://groups.google.com/groups?q=comp.lang.python .. _PEP Markup: http://www.python.org/peps/pep-0012.html .. _Docutils: http://docutils.sf.net/ .. _reST: .. _reStructuredText: http://docutils.sf.net/rst.html .. _PSF: .. _Python Software Foundation: http://python.org/psf/ .. _last summary: http://www.python.org/dev/summary/2005-02-15_2005-02-28.html .. _original text file: http://www.python.org/dev/summary/2005-03-01_2005-03-15.ht .. _archive: http://www.python.org/dev/summary/ .. _RSS feed: http://www.python.org/dev/summary/channews.rdf -- http://mail.python.org/mailman/listinfo/python-list
python-dev Summary for 2005-03-16 through 2005-03-31 (my last)
pipermail/python-dev/2005-March/052308.html>`__ - `[AST] A somewhat less trivial patch than the last one. . . <http://mail.python.org/pipermail/python-dev/2005-March/052336.html>`__ - `[AST] question about marshal_write_*() fxns <http://mail.python.org/pipermail/python-dev/2005-March/052340.html>`__ --- Putting docstrings before function declarations is ugly --- The idea of moving docstrings before a 'def' was proposed, making it like most other practices in other languages. But very quickly people spoke up against the suggestion. A main argument was people just like the current way much better. I personally like the style so much that even in my C code I put the comment for all functions after the first curly brace, indented to match the flow of code. There was also an issue of ambiguity. How do you tell where the docstring for a module is when there is a function definition with a comment right after?:: """Module doc""" """Fxn doc""" def foo(): pass There is an ambiguity there thanks to constant string concatenation. In the end no one seemed to like the idea. Contributing threads: - `docstring before function declaration <http://mail.python.org/pipermail/python-dev/2005-March/052406.html>`__ --- PyPI improvements thanks to PyCon sprinting --- Thanks to the hard work of Richard Jones, "Fred Drake, Sean Reifschneider, Martin v. LÃwis, Mick Twomey, John Camara, Andy Harrington, Andrew Kuchling, David Goodger and Ian Bicking (with Barry Warsaw in a supporting role)" accordinng to Richard, there are a bunch of new features to PyPI_ (pronounced "pippy" to prevent name clashes with PyPy). These improvements include using reST_ for descriptions, a new 'upload' feature for Distutils (requires Python 2.5), ability to sign releases using OpenPGP (requires Python 2.5), metadata fields are now expected to be UTF-8 encoded, interface cleanup, and saner URLs for projects (e.g., http://www.python.org/pypi/roundup/0.8.2). .. _PyPI: http://www.python.org/pypi/ Contributing threads: - `New PyPI broken package editing <http://mail.python.org/pipermail/python-dev/2005-March/052360.html>`__ - `Re: python/dist/src/Lib/distutils/command upload.py, 1.3, 1.4 <http://mail.python.org/pipermail/python-dev/2005-March/052362.html>`__ --- Decorators for class statements --- The desire to have decorators applied to class statements was brought up once again. Guido quickly responded, though, stating that unless a compelling use case that showed them much more useful than metaclasses it just would not happen. Contributing threads: - [EMAIL PROTECTED] of classes <http://mail.python.org/pipermail/python-dev/2005-March/052369.html>`__ === Skipped Threads === + itertools.walk() + Problems with definition of _POSIX_C_SOURCE + thread semantics for file objects Assume nothing is thread-safe + Draft PEP to make file objects support non-blocking mode. + Faster Set.discard() method? + __metaclass__ problem + Example workaround classes for using Unicode with csv module... + Change 'env var BROWSER override' semantics in webbrowser.py + bdist_deb checkin comments + Python 2.4 | 7.3 The for statement + Patch review: all webbrowser.py related patches up to 2005-03-20 + webbrowser.py: browser >/dev/null 2>&1 + C API for the bool type? + Shorthand for lambda + FYI: news items about Burton Report on P-languages + using SCons to build Python + 64-bit sequence and buffer protocol + Pickling instances of nested classes + python.org/sf URLs aren't working? Epilogue Introduction This is a summary of traffic on the `python-dev mailing list`_ from March 16, 2005 through March 31, 2005. It is intended to inform the wider Python community of on-going developments on the list on a semi-monthly basis. An archive_ of previous summaries is available online. An `RSS feed`_ of the titles of the summaries is available. You can also watch comp.lang.python or comp.lang.python.announce for new summaries (or through their email gateways of python-list or python-announce, respectively, as found at http://mail.python.org). This is the sixty-first summary written by Brett Cannon (it's been fun). To contact me, please send email to brett at python.org. Do *not* post to comp.lang.python if you wish to reach me. The `Python Software Foundation`_ is the non-profit organization that holds the intellectual property for Python. It also tries to advance the development and use of Python. If you find the python-dev Summary helpful please consider making a donat
Re: [Python-Dev] Python 2.x and 3.x use survey, 2014 edition
On Thu Dec 11 2014 at 3:14:42 PM Dan Stromberg wrote: > On Thu, Dec 11, 2014 at 11:35 AM, Mark Roberts wrote: > > I disagree. I know there's a huge focus on The Big Libraries (and > wholesale > > migration is all but impossible without them), but the long tail of > > libraries is still incredibly important. It's like saying that migrating > the > > top 10 Perl libraries to Perl 6 would allow people to completely ignore > all > > of CPAN. It just doesn't make sense. > > Things in the Python 2.x vs 3.x world aren't that bad. > > See: > https://python3wos.appspot.com/ and > https://wiki.python.org/moin/PortingPythonToPy3k > http://stromberg.dnsalias.org/~strombrg/Intro-to-Python/ (writing code > to run on 2.x and 3.x) > > I believe just about everything I've written over the last few years > either ran on 2.x and 3.x unmodified, or ran on 3.x alone. If you go > the former route, you don't need to wait for your libraries to be > updated. > > I usually run pylint twice for my projects (after each change, prior > to checkin), once with a 2.x interpreter, and once with a 3.x > interpreter (using > http://stromberg.dnsalias.org/svn/this-pylint/trunk/this-pylint) , but > I gather pylint has the option of running on a 2.x interpreter and > warning about anything that wouldn't work on 3.x. > Pylint 1.4 has a --py3k flag to run only checks related to Python 3 compatibility under Python 2. -- https://mail.python.org/mailman/listinfo/python-list
Re: [python-committers] [RELEASED] Python 3.4.0a2
On Mon, Sep 9, 2013 at 8:02 AM, Larry Hastings wrote: > > On behalf of the Python development team, I'm chuffed to announce the > second alpha release of Python 3.4. > > This is a preview release, and its use is not recommended for > production settings. > > Python 3.4 includes a range of improvements of the 3.x series, including > hundreds of small improvements and bug fixes. Major new features and > changes in the 3.4 release series so far include: > > * PEP 435, a standardized "enum" module > * PEP 442, improved semantics for object finalization > * PEP 443, adding single-dispatch generic functions to the standard library > * PEP 445, a new C API for implementing custom memory allocators > * PEP 446, changing file descriptors to not be inherited by default >in subprocesses > * PEP 447, a new magic method for metaclasses (``__typelookup__``) > * PEP 448, making automatic sequence unpacking more general > Those last two PEPs are still in draft form and not accepted nor have any committed code yet. -- https://mail.python.org/mailman/listinfo/python-list
Re: Porting Python Application to a new linux machine
On Thu, Sep 3, 2015 at 10:39 AM, Chris Angelico wrote: > On Fri, Sep 4, 2015 at 1:31 AM, Luca Menegotto > wrote: > > Il 03/09/2015 16:32, Heli Nix ha scritto: > > > >> How can I do this in Linux ? > > > > > > As far as I know, in general a Linux distro comes with Python already > > installed. > > All you have to do is check if the installed version matches your needs. > > Tipically, you'll find Python 2.7; however, I know there are distros with > > Python3.x as default (Fedora?) > > Also Ubuntu. If you want to work across multiple Linux distros, the > easiest way is to tell people to install either "python2" or "python3" > using their system package manager, and then use that. > > ChrisA > -- > https://mail.python.org/mailman/listinfo/python-list > You could also look into a more robust solution like placing your application environment into something like a Docker container. This would require your customer machine to be running Docker, but it makes deployments highly portable as the container will sit on top of just about any Linux flavor and can be entirely self contained. Brett -- https://mail.python.org/mailman/listinfo/python-list
Re: [TIP] Anyone still using Python 2.5?
On Wed, Dec 21, 2011 at 05:57, Jim Fulton wrote: > On Wed, Dec 21, 2011 at 2:15 AM, Chris Withers > wrote: > > Hi All, > > > > What's the general consensus on supporting Python 2.5 nowadays? > > > > Do people still have to use this in commercial environments or is > everyone > > on 2.6+ nowadays? > > > > I'm finally getting some continuous integration set up for my packages > and > > it's highlighting some 2.5 compatibility issues. I'm wondering whether to > > fix those (lots of ugly "from __future__ import with_statement" > everywhere) > > or just to drop Python 2.5 support. > > > > What do people feel? > > Google app engine is still Python 2.5, as is Jython. But App Engine also supports Python 2.7: http://code.google.com/appengine/docs/python/python27/ (currently experimental, but then again App Engine itself was in preview mode until just this past month). -- http://mail.python.org/mailman/listinfo/python-list
Re: how to find not the next sibling but the 2nd sibling or findsibling "a" OR sinbling "b"
[EMAIL PROTECTED] wrote:
> hey fredrik,
>
> i don't understand what you are saying
Do what he showed in the Python interactive shell,
> Fredrik Lundh wrote:
> > 'food' or 'drink' doesn't do what you think it does:
> >
> > >>> 'food' or 'drink'
> > 'food'
> >
> > >>> {'class': 'food' or 'drink'}
> > {'class': 'food'}
"or" returns the first true element, anything but False or None, I
think... so 'food' (a string) is true, and always will return in that
code.
http://diveintopython.org/power_of_introspection/and_or.html
Brett
--
http://mail.python.org/mailman/listinfo/python-list
Re: question about dictionaries
Chris wrote: > Is there a way to stop this behavior? I want to process this dictionary > in the order it's in, element by element. I'm running Python 2.3, if > that helps. As said previously, you either want a list (which are ordered), or an ordered-dictionary (not a Python native type, see http://www.voidspace.org.uk/python/odict.html) dict datatypes do not maintain any specific order and aren't really meant to, they're just handy, 'fast' hash lookups. Brett -- http://mail.python.org/mailman/listinfo/python-list
Four issue trackers submitted for Infrastructue Committee's tracker search
Back in June, the Python Software Foundation's Infrastructure Committee asked for help in the search for a new issue tracker to replace SourceForge (see http://wiki.python.org/moin/CallForTrackers for details). We asked people who wished to help with the search to install their favourite issue tracker and import a data dump of our issues from SourceForge. We placed a deadline of August 7th to have the installation up and going. We realized that this was a large request to make of the community, but we needed to make sure that we got to evaluate any candidate trackers with the amount of issues that Python has so as to get a real-world feel. Not surprisingly, the community stepped up to the challenge with four different test tracker installations by the deadline! We have one for JIRA, Roundup, Trac, and Launchpad. The current schedule calls for the Infrastructure Committee to spend the next month evaluating the four trackers and making a decision on which one to go with. This might slip, though, since this overlaps with traditional American and European vacation time. But the slippage will not go beyond October 1. On behalf of the Infrastructure committee I thank the people who took the time and effort to set up a test tracker to help improve the development of Python.- Brett Cannon Chairman, PSF Infrastructure Committee -- http://mail.python.org/mailman/listinfo/python-list
Re: Ok. This IS homework ...
spawn wrote:
> while running:
> guess = int(raw_input('Enter an integer that I can use to add : '))
> subtotal = guess
> while running:
> guess = int(raw_input('I\'ll need another number : '))
> running_total = guess + subtotal
You keep adding the original input (subtotal) to the most recent guess,
and printing "running_total". You never re-assign subtotal or make use
of running_total in your deepest loop.
Also, you never break out of your deepest loop, why are you using two
nested infinite-loops anyway?
Regards,
Brett Hoerner
--
http://mail.python.org/mailman/listinfo/python-list
Re: Ok. This IS homework ...
spawn wrote: > Actually, they do end. If I > move my "guess" variable outside the outermost loop, then it becomes > infinte. I know, I tried it. Huh? When does "running" ever evaluate to false (therefore breaking either of the loops)? -- http://mail.python.org/mailman/listinfo/python-list
Re: why should dict not be callable?
[EMAIL PROTECTED] wrote:
> A couple of times recently I've come across this problem: I have a
> large list to sort and I need to the the "key=function" argument to
> sort appropriately. But I actually have the key mapping in a big
> dictionary.
Is this what you mean? I suppose the lambda is an "intermediary
function" ... but meh...
l = ['bob', 'dog', 'cat', 'apple']
d = {'bob': 7, 'dog': 0, 'cat': 14, 'apple': 3}
l.sort(lambda x,y: d[x] - d[y])
print l
['dog', 'apple', 'bob', 'cat']
--
http://mail.python.org/mailman/listinfo/python-list
Re: Image.draft -- what are the modes that I can use?
abcd wrote: > ... Are you sure you can't use VNC? An animated GIF based on full-screen grabs will be amazingly huge and have very low color quality at the same time. Installing VNC on Windows should take you about 30 seconds, honest. Or is this for some sort of project where you can't use anything but CPython software...? Brett Hoerner -- http://mail.python.org/mailman/listinfo/python-list
PSF Infrastructure has chosen Roundup as the issue tracker for Python development
At the beginning of the month the PSF Infrastructure committee announced that we had reached the decision that JIRA was our recommendation for the next issue tracker for Python development. Realizing, though, that it was a tough call between JIRA and Roundup we said that we would be willing to switch our recommendation to Roundup if enough volunteers stepped forward to help administer the tracker, thus negating Atlassian's offer of free managed hosting. Well, the community stepped up to the challenge and we got plenty of volunteers! In fact, the call for volunteers has led to an offer for professional hosting for Roundup from Upfront Systems. The committee is currently evaluating that offer and will hopefully have a decision made soon. Once a decision has been made we will contact the volunteers as to whom we have selected to help administer the installation (regardless of who hosts the tracker). The administrators and python-dev can then begin working towards deciding what we want from the tracker and its configuration. Once again, thanks to the volunteers for stepping forward to make this happen!-Brett CannonPSF Infrastructure committee chairman -- http://mail.python.org/mailman/listinfo/python-list
Re: Negative integers and string formating
Steven D'Aprano wrote: > Are there any string formatting codes that will place a space between the > sign and the number? Not that I know of, why not use the absolute value (after checking if it is negative), In [1]: abs(-1) Out[1]: 1 -- http://mail.python.org/mailman/listinfo/python-list
Request for trackers to evaluate as SF replacement for Python development
The Python Software Foundation's Infrastructure committee has been charged with finding a new tracker system to be used by the Python development team as a replacement for SourceForge. The development team is currently unhappy with SF for several reasons which include: * Bad interface Most obvious example is the "Check to Upload" button* Lack of reliability SF has been known to go down during the day unexpectedly and stay down for hours* Lack of workflow controls For instance, you cannot delete a category once createdFor these reasons and others, we are requesting the Python community help us find a new tracker to use. We are asking for test trackers to be set up to allow us to test them to see which tracker we want to move the Python development team to. This is in order to allow the Infrastructure committee to evaluate the various trackers to see which one meets our tracker needs the best. Because we are not sure exactly what are requirements for a tracker are we do not have a comprehensive requirements document. But we do have a short list of bare minimum needs:* Can import SF data http://effbot.org/zone/sandbox-sourceforge.htm contains instructions on how to access the data dump and work with the support tools (graciously developed by Fredrik Lundh) * Can export data To prevent the need to develop our own tools to get our data out of the next tracker, there must be a way to get a dump of the data (formatted or raw) that includes *all* information* Has an email interface To facilitate participation in tracker item discussions, an email interface is required to lower the barrier to add comments, files, etc.If there is a tracker you wish to propose for Python development team use, these are the steps you must follow: * Install a test tracker If you do not have the server resources needed, you may contact the Infrastructure committee at infrastructure at python.org, but our resources are limited by both machine and manpower, so *please* do what you can to use your own servers; we do not expect you to provide hosting for the final installation of the tracker for use by python-dev, though, if your tracker is chosen * Import the SF data dump http://effbot.org/zone/sandbox-sourceforge.htm* Make the Infrastructure committee members administrators of the tracker A list of the committee members can be found at http://wiki.python.org/moin/PythonSoftwareFoundationCommittees#infrastructure-committee-ic * Add your tracker to the wiki page at http://wiki.python.org/moin/CallForTrackers This includes specifying the contact information for a *single* lead person to contact for any questions about the tracker; this is to keep communication simple and prevent us from having competing installations of the same tracker software * Email the Infrastructure committee that your test tracker is up and ready to be viewedWe will accept new trackers for up to a maximum of two months starting 2006-06-05 (and thus ending 2006-08-07). If trackers cease to be suggested, we will close acceptance one month after the last tracker proposed (this means the maximum timeframe for all of this is three months, ending 2006-09-04). This allows us to not have this process carry on for three months if there is no need for it to thanks to people getting trackers up quickly. As the committee evaluates trackers we will add information about what we like and dislike to the http://wiki.python.org/moin/GoodTrackerFeatures wiki page so that various trackers and change their setttings and notify us of such changes. This prevents penalizing trackers that are set up quickly (which could be taken as a sign of ease of maintenance) compared to trackers that are set up later but possibly more tailored to what the Infrastructure committee discovers they want from a tracker. If you have any questions, feel free to email infrastructure at python.org .- Brett Cannon Chairman, Python Software Foundation Infrastructure committee -- http://mail.python.org/mailman/listinfo/python-list
About a month until PSF call for test trackers closes!
Back at the beginning of June, the Python Software Foundation's Infrastructure committee sent out an email requesting people to help us find a replacement tracker for SourceForge (the original announcement can be found at http://wiki.python.org/moin/CallForTrackers ). We asked that people put test trackers loaded with a data dump of Python's SourceForge tracker data online for us to play with. We said that we would close acceptance of test trackers as of August 7. That close date is a little over a month away! If you want to help get your favorite tracker up and going for the Infrastructure committee to evaluate, please visit http://wiki.python.org/moin/CallForTrackers and see if you can help out! We already have a tracker for JIRA up and loaded with the SF data to poke around with. There are also Trac and Roundup trackers in the planning stages that could use some help in getting the SF data imported and getting the servers up. In order for a tracker to be considered it *must* have the SF data loaded up. This will be a necessary step if the tracker is accepted, plus it lets us see how well the tracker lets us manage a large number of bugs. If you have questions or concerns, please email infrastructure at python.org (it is subscription-protected, but your email will be accepted; the subscription page is at http://mail.python.org/mailman/listinfo/infrastructure ). Thank you to those that have helped so far and those that do in the future.-Brett CannonChairman, PSF Infrastructure Committee -- http://mail.python.org/mailman/listinfo/python-list
Re: preserving color ouput of a shell command via os.popen()
[EMAIL PROTECTED] wrote:
> child = os.popen("ls --color=auto")
> output = child.read()
>
> results in an output string which is free of the escape sequences
> generated by ls.
Don't use --color=auto, from the 'ls' man page:
With --color=auto, color codes are output only if standard output is
connected to a terminal (tty).
'ls' doesn't think Python is a color terminal, so just use "--color",
ie:
>>> import os
>>> a = os.popen("ls --color /")
>>> f = a.read()
>>> f
'\x1b[00m\x1b[00;34mbin\x1b[00m\n\x1b[00;34mboot\x1b[00m\n\x1b[00;34mdev\x1b[00m\n\x1b[00;34metc\x1b[00m\n\x1b[00;34mhome\x1b[00m\n\x1b[00;34mlib\x1b[00m\n\x1b[00;34mlost+found\x1b[00m\n\x1b[00;34mmedia\x1b[00m\n\x1b[00;34mmisc\x1b[00m\n\x1b[00;34mmnt\x1b[00m\n\x1b[00;34mnet\x1b[00m\n\x1b[00;34mopt\x1b[00m\n\x1b[00;34mproc\x1b[00m\n\x1b[00;34mroot\x1b[00m\n\x1b[00;34msbin\x1b[00m\n\x1b[00;34mselinux\x1b[00m\n\x1b[00;34msrv\x1b[00m\n\x1b[00;34msys\x1b[00m\n\x1b[00;34mtmp\x1b[00m\n\x1b[00;34musr\x1b[00m\n\x1b[00;34mvar\x1b[00m\n\x1b[m'
>>> a = os.popen("ls --color=auto /")
>>> f = a.read()
>>> f
'bin\nboot\ndev\netc\nhome\nlib\nlost+found\nmedia\nmisc\nmnt\nnet\nopt\nproc\nroot\nsbin\nselinux\nsrv\nsys\ntmp\nusr\nvar\n'
>>>
See the difference? :)
Brett Hoerner
--
http://mail.python.org/mailman/listinfo/python-list
Re: calling a class instance of function
Pyenos wrote: > class test(pid): > pid.original=[1,2,3] > pid.toadd=4 > pid.add(pid.original,pid.toadd) # error here says that > # it expects pid instance as first arg > # not a list that it got. > > why do i get an error? 'test' is a class here, and the pid you tried to pass it is actually the class it is inheriting from. I think you wanted to do: def test(pid): ... Also, in order to call a function without arguments you still need to use (), so you probably wanted to use pid.original() in your pid.add call. Brett Hoerner -- http://mail.python.org/mailman/listinfo/python-list
Re: calling a class instance of function
Brett Hoerner wrote: > Also, in order to call a function without arguments you still need to > use (), so you probably wanted to use pid.original() in your pid.add > call. Sorry, never mind this bit, I misread the line. But you do probably want to change the class test into a function test. Brett Hoerner -- http://mail.python.org/mailman/listinfo/python-list
RE: Python-list Digest, Vol 29, Issue 147
nope, we where one short plus mark just pulled out so now we're two short. if
you can get ANYONE that would be great?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf
Of [EMAIL PROTECTED]
Sent: 10 February 2006 02:21
To: python-list@python.org
Subject: Python-list Digest, Vol 29, Issue 147
Send Python-list mailing list submissions to
python-list@python.org
To subscribe or unsubscribe via the World Wide Web, visit
http://mail.python.org/mailman/listinfo/python-list
or, via email, send a message with subject or body 'help' to
[EMAIL PROTECTED]
You can reach the person managing the list at
[EMAIL PROTECTED]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Python-list digest..."
IMPORTANT NOTICE:
If you are not the intended recipient of this email (or such person's
authorised representative), then :
(a) please notify the sender of this email immediately by return email,
facsimile or telephone and delete this message from your system;
(b) you may not print, store, forward or copy this message or any part thereof
or disclose or cause information in this message to be
disclosed to any other person.
The information in or attached to this email message is confidential and may be
subject to legal privilege and client confidentiality.
In addition this message is subject to important restrictions, qualifications
and disclaimers ("the disclaimer") that must be accessed and
read by copying the following address into your Internet browser's address bar
: http://www.investec.com/emaildisclaimer/
The disclaimer also provides our corporate information and names of our
directors as required by law.
The disclaimer is deemed to form part of this message in terms of Section 11 of
the Electronic Communications and Transactions Act 25 of 2002.
If you cannot access the disclaimer, please obtain a copy thereof from us by
sending an email to : [EMAIL PROTECTED]
Certain entities within the Investec group of companies are registered as
authorised financial services providers.
The details of these entities are available on our website :
http://www.investec.com/southafrica
--
http://mail.python.org/mailman/listinfo/python-list
Re: ordered sets operations on lists..
On 2/12/06, Felipe Almeida Lessa <[EMAIL PROTECTED]> wrote: > Em Dom, 2006-02-12 às 23:15 -0500, Steve Holden escreveu: > > Given that Python 2.4 doesn't even perform simple constant folding for > > arithmetic expressions > > [snip] > > May I ask why doesn't it perform such optimization? Is there any special > difficulties in doing so with the Python compiler? It does in 2.5 thanks to Raymond Hettinger: >>> import dis [18110 refs] >>> def simple(): print 1+2 ... [18136 refs] >>> dis.dis(simple) 1 0 LOAD_CONST 3 (3) 3 PRINT_ITEM 4 PRINT_NEWLINE 5 LOAD_CONST 0 (None) 8 RETURN_VALUE [18635 refs] >>> Simple, low-hanging fruit like this are covered by the peephole optimizer already. Anything more complex, though, is difficult thanks to things being so dynamic and thus not easy to guarantee to be correct between compile-time and run-time. -Brett -- http://mail.python.org/mailman/listinfo/python-list
Localized Type Inference of Atomic Types in Python
My thesis, "Localized Type Inference of Atomic Types in Python", was successfully defended today for my MS in Computer Science at the California Polytechnic State University, San Luis Obispo. With that stamp of approval I am releasing it to the world. You can grab a copy at http://www.drifty.org/thesis.pdf . For those of you who attended my talk at PyCon 2005 this is the thesis that stemmed from the presented data. As of this exact moment I am not planning to release the source code mainly because it's a mess, I am not in the mood to pull the patches together, and the last thing I want happening is people finding mistakes in the code. =) But if enough people request the source I will take the time to generate a tar.bz2 file of patches against the 2.3.4 source release and put them up somewhere. Below is the abstract culled directly from the thesis itself. -Brett C. - ABSTRACT Types serve multiple purposes in programming. One such purpose is in providing information to allow for improved performance. Unfortunately, specifying the types of all variables in a program does not always fit within the design of a programming language. Python is a language where specifying types does not fit within the language design. An open source, dynamic programming language, Python does not support type specifications of variables. This limits the opportunities in Python for performance optimizations based on type information compared to languages that do allow or require the specification of types. Type inference is a way to derive the needed type information for optimizations based on types without requiring type specifications in the source code of a program. By inferring the types of variables based on flow control and other hints in a program, the type information can be derived and used in a constructive manner. This thesis is an exploration of implementing a type inference algorithm for Python without changing the semantics of the language. It also explores the benefit of adding type annotations to method calls in order to garner more type information. -- http://mail.python.org/mailman/listinfo/python-list
Re: getting the size of an object
On Jun 18, 11:07 am, "filox" <[EMAIL PROTECTED]> wrote: > is there a way to find out the size of an object in Python? e.g., how could > i get the size of a list or a tuple? "Size" can mean a lot of things, len(my_list) len(my_tuple) Although I have the feeling you mean "how many bytes does this object take in memory" - and I believe the short answer is no. Brett -- http://mail.python.org/mailman/listinfo/python-list
Re: getting the size of an object
On Jun 18, 2:48 pm, "filox" <[EMAIL PROTECTED]> wrote: > is there a long answer? what i want is to find out the number of bytes the > object takes up in memory (during runtime). since python has a lot of > introspection mechanisms i thought that should be no problem... There isn't an automatic way through the language afaik. I think allocating memory in order to keep track of how much memory you have allocated can begin to be a problem. And most people just don't care down to each and every byte. :) Some helpful information here: http://groups.google.com/group/comp.lang.python/browse_thread/thread/a7b9f3c03fb49aa/0e793beec82884f0?lnk=gst&q=size+object&rnum=4#0e793beec82884f0 Brett -- http://mail.python.org/mailman/listinfo/python-list
Secured CPython interpreter in embedded situations
I have been working on making Python a secure interpreter to run when embedded in terms of resources with an object representation (e.g., files but not memory or CPU). To save myself from repeating myself and missing some details of exactly what I have done I am going to point to a post to my Python blog (and I have replied to people in the comments so if you have a question it may have been answered there): http://sayspy.blogspot.com/2007/05/i-have-finished-securing-python.html . With no one having told me they have found a hole in the design I am ready to make a wider announcement here. If you have a use for a secured CPython interpreter then please have a look (although the work generalizes to the language, I implemented it in CPython since that is what I know best). This work is not about replacing rexec, though! It secures the entire interpreter and is not about running some Python code at a higher privilege level than some other code. If you manage to check out the code and get it run, let me know (I have one report of someone getting it to compile but erroring out immediately but I can't reproduce it as it still works for me after a ``make distclean``). And if you do manage to break the security model (manage to open a file, import a module that is not whitelisted, etc.), then PLEASE let me know! If the work holds up I will make an announcement in c.l.py.a and then start the process to get my changes into the trunk so that you don't need to use a branch. Thanks in advance to anyone who gives the code a whirl. -Brett -- http://mail.python.org/mailman/listinfo/python-list
Moving Python's tracker to Roundup on Aug 23rd
On August 23rd Python will be moving off of SourceForge and over to our own issue tracker run on Roundup (http://bugs.python.org/). During the transition there will be a time where the SourceForge tracker is no longer being used but that the new tracker has not been brought up yet. We expect this gap to be for a few hours. But to minimize issues, please try to avoid using either SourceForge or the new issue tracker on Aug 23rd if you can. -Brett Cannon Chairman, PSF Infrastructure committee -- http://mail.python.org/mailman/listinfo/python-list
Issue tracker migration is complete
Thanks to the work of Erik Forsberg and Martin von Löwis, Python's issue tracker now lives at http://bugs.python.org . Because this is a new tracker on a new system you cannot use your SourceForge password on the new tracker. But account names have been migrated, so if you go to "Lost your login?" and follow the instructions for SF accounts you can continue to use the same account name on the new tracker (you can also change it once you get a new password). And if you come across any bugs in the tracker, please report them using the "Report Tracker Problem" link. There are a bunch of people to thank for making this all happen. Beyond the huge thanks to Erik (http://efod.se/) and Martin, other people heavily involved include Paul DuBois for coming forward as another tracker admin, the guys at Upfront Systems (http://www.upfrontsystems.co.za/) providing the hosting, Skip Montanaro for working on an anti-spam system, Stefan Seefeld for helping with the test tracker back when this whole process started, the Python Software Foundation's Infrastructure committee for helping choose a tracker, and all the people who participated on the tracker-discuss mailing list. And if I forgot someone, thanks to them as well. =) -Brett Cannon Chairman, PSF Infrastructure committee -- http://mail.python.org/mailman/listinfo/python-list
Curses and Threading
I am writing a program that uses curses and threading. I am working on
displaying a clock in the upper right hand corner of the screen. I
have only one thread at the moment, that gets the time and displays it
in curses. To make it easier to debug right now, the program starts
curses in a try: clause then starts the thread which runs for 10
iterations displaying the time every second. Then the thread exits,
and the program is supposed to run the finally: clause to clean up the
terminal. I also have set curs_set(0) so the cursor is invisible. What
happens is that everything starts fine but the cursor is visible. It
runs for the 10 seconds then quits without restoring the terminal to
working order. I am trying this on a Fedora 4 computer have also tried
it on a Fedora 8 one with same results. I have tried searching but
Google doesn't find anything using both curses and threading. The only
thing I can find regarding both is that curses seems to block when
waiting for input, but I do not have any input yet. Below is what I
have right now:
#! /usr/bin/env python
import curses
import threading
import time
class cadtime(threading.Thread):
def run(self):
x=0
while x<10:
cadtimevl=time.strftime("%d %b %H:%M:
%S",time.localtime())
leng=len(cadtimevl)
stdscr.addstr(0,width-leng-1,cadtimevl)
stdscr.refresh()
x=x+1
time.sleep(1)
return
try:
stdscr=curses.initscr()
curses.noecho()
curses.cbreak()
stdscr.keypad(1)
curses.start_color()
curses.curs_set(0)
width=curses.COLS-1
cadtime().start()
finally:
curses.nocbreak()
stdscr.keypad(0)
curses.echo()
curses.endwin()
I can't figure out why the cursor still shows and why they terminal is
screwed up afterward because the finally: should catch any failures
and reset the terminal.
-Brett
--
http://mail.python.org/mailman/listinfo/python-list
Re: Curses and Threading
> In fact you have *two* threads: the main thread, and the one you create > explicitly. > After you start the clock thread, the main thread continues executing, > immediately entering the finally clause. > If you want to wait for the other thread to finish, use the join() method. > But I'm unsure if this is the right way to mix threads and curses. This is what the python documentation says: join([timeout]) Wait until the thread terminates. This blocks the calling thread until the thread whose join() method is called terminates. So according to this since I need to block the main thread until the clock thread ends I would need the main thread to call "cadtime().join()", correct? I'm not sure how to do this because I don't have a class or anything for the main thread that I know of. I tried putting that after cadtime().start() but that doesn't work. I guess what I'm trying to say is how can I tell the main thread what to do when it doesn't exist in my code? Thanks for the help -Brett -- http://mail.python.org/mailman/listinfo/python-list
Announcing the Python core sprint at PyCon 2008
As has occurred since the inception of PyCon, there will be a sprint on the Python core at this year's conference! If you will be attending PyCon (or will be in Chicago during the dates of the sprints), attending the sprint is a great way to give back to Python. Working on Python itself tends to deepens one knowledge of the language and the standard library. Plus it is just plain fun getting to sit around some tables with fellow Python programmers for several days (the sprint will last four days, but you do not need to attend all four days to participate). The sprint is open to everyone of all skill levels. We can always use help with things from updating documentation to preparing for the next release of Python 3.0. On Sunday evening of the conference there will not only be a sprint intro session, but also a tutorial on how to develop for Python. Details will be covered from where to look in the code base for things to some best practices tips. If you are interested enough to want to sign up to attend, please go to http://wiki.python.org/moin/PyCon2008/SprintSignups/Python and add your name and email address. If you have questions you may email me. Please sign up for the sprint by the end of February as an email on what you need to do beforehand will be sent at that time based on the sprint sign-up page. And if you are not attending PyCon, we will most likely have several people in attendance on IRC, thus allowing even people not at PyCon to participate! -Brett Cannon Python core sprint coach, PyCon 2008 -- http://mail.python.org/mailman/listinfo/python-list
Re: Curses and Threading
> join() is a method on Thread objects. So you'll need a reference to the > Thread you create, then call join() on that. > > thread = cadtime() > thread.start() > thread.join() > > Ian Thanks for all the help guys. It's working great. Just one more question, I think. As you probably guessed, I want to have a second and possibly third thread. I tried calling it in different ways, but if the first one is joined the second one will not run. But if the first one is not joined curses exits early like before. If I can figure out how to use multiple threads with curses now I think I will be set. -Brett -- http://mail.python.org/mailman/listinfo/python-list
Call for volunteers to help maintain bugs.python.org's issue tracker
The Python Software Foundation's infrastructure committee is looking for volunteers to help maintain the Roundup issue tracker installed for http://bugs.python.org. Responsibilities revolve around maintaining the Roundup installation itself (tracker schema, modifying the installed copy of Roundup, etc.) and the occasional database work (changes to the database, etc.). You do not have to be an expert at Roundup to volunteer! You can learn "on the job" by doing offline development and submitting patches until you are of a proper level of experience to gain commit access to the code (which can be seen at XXX). If you still have a New Years resolution to help Python out this is a great way to fulfill the promise you made yourself for 2008! If you are interested in volunteering, please email tracker-discuss at python.org. Thanks to all who have helped with the tracker already and those that will in the future! -Brett Cannon Chairman, PSF infrastructure committee -- http://mail.python.org/mailman/listinfo/python-list
Re: [Python-Dev] [ANN] Python 2.3.7 and 2.4.5, release candidate 1
On Sun, Mar 2, 2008 at 4:52 PM, Fred Drake <[EMAIL PROTECTED]> wrote: > On Mar 2, 2008, at 7:43 PM, Fred Drake wrote: > > 2.4.5 won't build for me from the svn checkout on Mac OS X 10.5.2: > > > Neither does 2.3.7 now that I've tried that: > > gcc -u __dummy -u _PyMac_Error -framework System -framework > CoreServices -framework Foundation -o python.exe \ > Modules/python.o \ > libpython2.3.a -ldl > Undefined symbols: >"__dummy", referenced from: > ld: symbol(s) not found > collect2: ld returned 1 exit status > make: *** [python.exe] Error 1 > > Of course, I wasn't using an earlier 2.3.x version on this box. I > would really like to be able to use 2.4.5, since I've been using 2.4.4 > for work for a while now. For me on OS X 10.5.2 (gcc 4.0.1) for 2.37 I am getting a ton of: sem_post: Bad file descriptor sem_init: Function not implemented sem_trywait: Bad file descriptor -Brett -- http://mail.python.org/mailman/listinfo/python-list
Re: Tuple parameter unpacking in 3.x
On Oct 5, 9:13 am, Terry Reedy <[EMAIL PROTECTED]> wrote: > Martin Geisler wrote: > > Steven D'Aprano <[EMAIL PROTECTED]> writes: > >>> From reading the PEP-3113 I got the impression that the author > >>> thought that this feature was unused and didn't matter. > > And that there were good alternatives, and that there were technical > reasons why maintaining the feature in the face of other arguments > options would be a nuisance. > As the author of PEP 3113, I should probably say something (kudos to Python-URL bringing this thread to my attention). There are two things to realize about the tuple unpacking that acted as motivation. One is supporting them in the compiler is a pain. Granted that is a weak argument that only the core developers like myself care about. Second, tuple unpacking in parameters breaks introspection horribly. All one has to do is look at the hoops 'inspect' has to jump through in order to figure out what the heck is going on to see how messy this is. And I realize some people will say, "but if 'inspect' can handle it, then who cares about the complexity", but that doesn't work if 'inspect' is viewed purely as a simple wrapper so you don't have to remember some attribute names and not having to actually perform some major hoops. I personally prefer being able to introspect from the interpreter prompt without having to reverse-engineer how the heck code objects deal with tuple unpacking. > >>> With this I wish to say that it matters to me. > Well, every feature matters to someone. Question is whether it matters to enough people to warrant having a feature. I brought this up at PyCon 2006 through a partially botched lightning talk and on python- dev through the PEP, so this was not some snap decision on my part that I rammed through python-dev; there was some arguing for keeping it from some python-dev members, but Guido agreed with me in the end. If you still hate me you can find me at PyCon 2009 and tar & feather me *after* my talk. =) > >> Alas, I think it's too late. I feel your pain. > > > Thanks! And I know it's too late, I should have found out about this > > earlier :-( > > For future reference, the time to have said something would have been > during the 3 month alpha phase, which is for testing feature and api > changes. I suspect, from reading the pydev discussion, that the answer > still would have been to either use a def statement and add the unpack > line or to subscript the tuple arg to stick with lambda expressions. > But who knows? I have not read this whole thread thoroughly, but it sounds like using iterator unpacking at the call site (e.g., ``fxn(*args)`` when calling your lambda) is out of the question because it is from a callback? As Terry said, the alpha is one way you can give feedback if you don't want to follow python-dev or python-3000 but still have your opinion be heard. The other way is to subscribe to the PEP news feed (found off of http://www.python.org/dev/peps/) to keep on top of PEPs as practically all language changes have to result in a PEP at some point. And of course the last option is to follow python-dev. =) -Brett -- http://mail.python.org/mailman/listinfo/python-list
Using xreadlines
Hi,
I am using both xreadlines and files iterators for a script that I need to
finish. I am iterating over the entire file but stopping to use xreadlines to
grab certain lines as strings to process them.
My question is how do I go to a previous line in the file? xreadlines has a
file.next() statement that gives the next line, and I need a statement that
gives me the previous line.
My script has a loop that looks for a certain word then breaks the loop. But I
need to go to the previous line before I break since the script uses that line
(which gets processed). I'm sure there is an easier way to do this but since I
am new to python and have spent a lot of time on this script I can't really go
back and change a lot of things unless there is no possible way. Something like
the example below.
f.open("text.txt",'r')
files = f.xreadlines()
Name = "Section 1"
for line in f:
if Name in line:
while x<20
field = files.next()
if "2.6" in field:
*files.previousline()*
break
x=x+1
Thanks,
Brett
--
http://mail.python.org/mailman/listinfo/python-list
Re: Using xreadlines
> You can also keep track of the absolute position of the lines in the file, > etc, or step back looking for newlines, etc, but it's not handy. How would I keep track of the absolute position of the lines? I have tried to use the files.seek() command with the files.tell() command and it does not seem to work. The files.tell() command seems to give me a number but when I use the files.next() command with xreadlines it does not change the line number the next time I use files.tell(). Thanks, Brett --- On Thu, 2/26/09, bearophileh...@lycos.com wrote: > From: bearophileh...@lycos.com > Subject: Re: Using xreadlines > To: python-list@python.org > Date: Thursday, February 26, 2009, 8:09 PM > Brett Hedges: > > My question is how do I go to a previous line in the > file? xreadlines has a file.next() statement that gives the > next line, and I need a statement that gives me the previous > line.< > > In modern versions of Python you usually don't need > xreadlines, > because files are iterable. > > If your files are small, you can just read all the lines in > a list > with open(...).readlines(), and then just use the item of > the list > with the n-1 index. > > If the file is quite large or you like to keep things lazy, > then you > have to keep memory of the previous line, using an > auxiliary variable. > You can also wrap this idiom into a generator function (or > iterable > class, probably) that yields items and keeps memory of the > last one > (but you can't ask the previous of the first item, of > course). > > You can also keep track of the absolute position of the > lines in the > file, etc, or step back looking for newlines, etc, but > it's not handy. > > Bye, > bearophile > -- > http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: [Python-Dev] PEP 382: Namespace Packages
On Fri, Apr 3, 2009 at 13:15, "Martin v. Löwis" wrote:
> > Note that there is no such thing as a "defining namespace package" --
> > namespace package contents are symmetrical peers.
>
> With the PEP, a "defining package" becomes possible - at most one
> portion can define an __init__.py.
>
> I know that the current mechanisms don't support it, and it might
> not be useful in general, but now there is a clean way of doing it,
> so I wouldn't exclude it. Distribution-wise, all distributions
> relying on the defining package would need to require (or
> install_require, or depend on) it.
>
> > The above are also true for using only a '*' in .pkg files -- in that
> > event there are no sys.path changes. (Frankly, I'm doubtful that
> > anybody is using extend_path and .pkg files to begin with, so I'd be
> > fine with a proposal that instead used something like '.nsp' files that
> > didn't even need to be opened and read -- which would let the directory
> > scan stop at the first .nsp file found.
>
> That would work for me as well. Nobody at PyCon could remember where
> .pkg files came from.
>
> > I believe the PEP does this as well, IIUC.
>
> Correct.
>
> >> * It's possible to have a defining package dir and add-one package
> >> dirs.
> >
> > Also possible in the PEP, although the __init__.py must be in the first
> > such directory on sys.path.
>
> I should make it clear that this is not the case. I envision it to work
> this way: import zope
> - searches sys.path, until finding either a directory zope, or a file
> zope.{py,pyc,pyd,...}
> - if it is a directory, it checks for .pkg files. If it finds any,
> it processes them, extending __path__.
> - it *then* checks for __init__.py, taking the first hit anywhere
> on __path__ (just like any module import would)
Just so people know how this __init__ search could be done such that
__path__ is set from the .pkg is to treat it as a reload (assuming .pkg
files can only be found off of sys.path).
-Brett
> - if no .pkg was found, nor an __init__.py, it proceeds with the next
> sys.path item (skipping the directory entirely)
>
--
http://mail.python.org/mailman/listinfo/python-list
Re: Lisp mentality vs. Python mentality
On Apr 25, 8:11 am, "Ciprian Dorin, Craciun"
wrote:
> Well in fact I would have written it like:
>
> def validate_commandline(rexes, line) :
> if not compare (rexes, line, re.match) :
> if len (rexes) != len (line) :
> raise ValueError ("mismatch len")
> mismatch = find_index (rexes, line, re.match, negate = True)
> raise ValueError ("mismatch at %d" % (mismatch))
>
> Assuming, that I would have the function find_index.
>
> Ciprian.
I think you've hit on the definition of "unpythonic". (No, I don't
have a dictionary definition for you, sorry).
Using a function called "compare" to run a list of regexes against
another list of regexes to get a boolean? And then another find_index
function doing the same where you pass in negate? What is even going
on here?
I, for one, would take Martin's any day of the week. It reads like
good pseudocode as much "proper" Python does.
Brett
--
http://mail.python.org/mailman/listinfo/python-list
Pickling exception object works in 2.4 but not 2.5
In 2.5, this is what I get:
Python 2.5.2 (r252:60911, May 7 2008, 15:19:09)
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class Foo(Exception):
... member = None
... def __init__(self,member):
... self.member=member
...
>>> import cPickle
>>> str = cPickle.dumps(Foo('testmember'))
>>> f2 = cPickle.loads(str)
Traceback (most recent call last):
File "", line 1, in
TypeError: ('__init__() takes exactly 2 arguments (1 given)', , ())
In 2.4 I don't get an error. Is there something I am doing wrong?
Thanks.
--
http://mail.python.org/mailman/listinfo/python-list
New to Python, familiar with Perl - Seeking info sources
After many years happily coding Perl, I'm looking to expand my horizons. [no flames please, I'm pretty aware of Perl's strengths and weaknesses and I'm just here to learn more, not to enter religious debates]. I've gone through some of the online tutorials and I'll be browsing the reference before starting the "code a lot" phase. My question is: What are the best sources to learn best practices or get the answers to questions? Are there any good sources to tell me what Perl habits are good/bad in the Python paradigm? What about common packages that will change my life? (I do a lot of web work, but also a lot of DB reporting) I'm also working as a Java developer primarily, so I'm glad to see that Jython has been resurrected, but I'm focusing on vanilla Python for the moment. As examples: PerlMonks has been my info source. The Perl Best Practices and Higher Order Perl books have been my tutors into better coding practices. CPAN has my life easy, giving me access to the DBI, Class::DBI (and its successors), HTML::FillInForm, Data::FormValidator, CGI::Application, and Text::CSV::Simple modules that are staples of my coding. The (occasionally complete) Perl Advent calendars have proven to be a good source to learn about helpful modules that I might not otherwise stumble across. (I've encountered Django, but I'm getting my fill of "frameworks" from Java for the moment, so I'm looking for lightweight pieces at the moment) My (admittedly brief) searches here and on google didn't lead me to any particular spots of concentrated Python info, and most of the Perl/ Python stuff is either a smug attack by one camp on the other or a rant about the behavior of an obscure feature between the two. Any recommendations? Thanks in advance. -- http://mail.python.org/mailman/listinfo/python-list
Simple Path issues
New to Python, and I have some questions on how to best set up a basic development environment, particular relating to path issues. Note: I am not root on my development box (which is some flavor of BSD) Where should I develop my own modules so as to refer to them in the standard way. I.E. I want: import proj to work regardless of my current working directory, and to function as if "proj" were a core or third-party module. I saw that I can set PYTHONPATH, but that seems sub-prime. I noted that in installing pysqlite (the local installation of python is 2.4) that I had it install in a lib under my home dir...should I use that locale? What is the command to tell me what directories python is checking in? While I'm at it, what is the best (read: standard) locale to stick my test cases? same dir as my project? A subdir? Thanks in advance -- http://mail.python.org/mailman/listinfo/python-list
Re: Simple Path issues
On Jul 26, 2:57 pm, Gary Josack <[EMAIL PROTECTED]> wrote: > sys.path is a list that will tell you where python is looking. You can > append to this in your scripts to have python look in a specific > directory for your own modules. I can, but that is almost certainly not the standard way to develop a module. I see nothing in sys.path that I have write permissions to. Is altering my PYTHONPATH the normal way to develop (under the assumption that later users will install in their conventional python search path)? -- http://mail.python.org/mailman/listinfo/python-list
Re: Module clarification
On Jul 28, 4:54 am, Hussein B <[EMAIL PROTECTED]> wrote: > Hi. > I'm a Java guy and I'm playing around Python these days... > In Java, we organize our classes into packages and then jarring the > packages into JAR files. > What are modules in Python? > What is the equivalent of modules in Java? I'm new myself, coming from Perl and Java. Take my comments with the appropriate salt. Here's my understanding: 1) JARs are a bit of a Java oddity. The other languages I've worked with don't really combine their packaging method for transport with their packaging method of access. Put another way, you may get a zipfile or tarball of library files, but they aren't USED in that format, they are just transported in that format. You unzip them and use the compiled libraries directly. Java appears to be unusual there. I could be wrong (it's a big world), but such is my experience in the C and Perl worlds. 2) Java also dictates a single class per file (basically). Other languages do not have that restriction which leads to different collections. A file in Python (a module) may have several classes, or just one, or none. A package in Python is a directory containing modules (and possibly other packages) as well as a __init__.py file. This means that you cannot have the Java case of two packages offering the same fully qualified resource, because the namespace is tied to the filesystem (note you can alter this when importing the packages). 3) Java uses "import" to create a shortcut to the namespace, a convenience for the programmer that has little to no bearing on the execution of the code. Namespace is determined by the classloader. Python uses "import" to declare how a namespace is used by the code itself, which can be very significant, (For example, Java can access any fully qualified package without an import statement. Python cannot access any package until it has been made available by import.) Hope that helps and is remotely accurate. I'm sure someone will correct me if I'm wrong. -- http://mail.python.org/mailman/listinfo/python-list
Re: What Python looks like
On Aug 4, 3:43 pm, Gary Herron <[EMAIL PROTECTED]> wrote: > A page of Python code looks *clean*, with not a lot of > punctuation/special symbols and (in particular) no useless lines I am actually going to buck the trend. My first impression of Python was that it was visually hard to parse. When seeing sample code from languages I don't know (.NET, Smalltalk, etc) I can decipher the intent fairly easily (on simple code). Python, on the other hand, used shorthand notation for everything. Each word wasn't bad, but as a whole it tended to wash out informative clues. The lack of "special symbols" likewise removed visual parsing clues. Put another way, imagine math went from: 2 + 2 = 4 to: two plus two equals four and then someone decided to abbreviate: two pl two eq four When I ran into list comprehensions (Aah! Now we have punctuation, but it's not providing visual parsing clues, it's more like Lisp parens!) or lambda definitions or "self" being added a lot, it grew more dense. This is NOT a rip on Python. Please put the flamethrowers away. I appreciate that Python operates with a fairly dense use of information and operations. (Believe me, having done enough Java, I can appreciate not having excessive syntax). My point is that not everyone new to Python is going to have a "clean and clear" first impression, particularly based on their previous language experience. -- http://mail.python.org/mailman/listinfo/python-list
Fixing PDF EOF Errors with PyPDF
Hey all, I'm trying to read a library of my company's PDFs, but about a
third of them can't be opened. PyPDF (v1.12) spits out this error:
pyPdf.utils.PdfReadError: EOF marker not found
I searched for the answer via google, but all I found was this link:
http://lindaocta.com/?tag=pypdf. She suggests fixing the problem by
appending an EOF marker like so:
def fixPdf(pdfFile):
try:
fileOpen = file(pdfFile, "a")
fileOpen.write("%%EOF")
fileOpen.close()
return "Fixed"
except Exception, e:
return "Unable to open file: %s with error: %s" % (pdfFile, str(e))
Which appears to successfully append all of the files, as the exception is
never triggered and "Fixed" always returned,
but subsequent attempts to open the files all failed. Yet all of those
files can be open successfully with Adobe Acrobat Reader.
Is this code inorrect or is there some other way to correct this error? Or
does the code depend on the system?
(I'm using Windows XP, but I believe the author was using a *nix)
Sincerely,
Brett Bowman
--
http://mail.python.org/mailman/listinfo/python-list
Cannot Remove File: Device or resource busy
I'm spawning a subprocess to fix some formating errors with a library of
PDFs with pdftk:
try:
sp = subprocess.Popen('pdftk.exe "%s" output %s' % (pdfFile,
outputFile))
sp.wait()
del sp
except Exception, e:
return "Unable to open file: %s with error: %s" % (pdfFile, str(e))
And then I test the result:
try:
pdf_handle = open(outputFile, "rb")
pdf_pypdf = PdfFileReader(pdf_handle)
del pdf_pypdf
del pdf_handle
except Exception, e:
return "Unable to open file: %s with error: %s" % (outputFile,
str(e))
Both of which appear to work. But when I try to delete the original
pdfFile, I get an error message saying that the file is still in use.
if I use:
sp = subprocess.Popen('rm "%s"' % pdfFile)
sp.wait()
I get the message - the standard error message from rm
and if I use:
cwd = os.getcwd()
os.remove(cwd + "\\" + pdfFile)
I get "WindowsError: [Error 32]" saying much the same thing.
What am I missing? Any suggestions would be appreciated.
Details:
Python 2.6
Windows XP
Sincerely,
Brett Bowman
--
http://mail.python.org/mailman/listinfo/python-list
Re: Cannot Remove File: Device or resource busy
Good ideas, but I've tried them already: -No del command, or replacing it with a set-to-null, neither solve my file access problem. -PdfFileReader has no close() function, and causes an error. Weird, but true. -pdf_handle.close() on the other hand, fails to solve the problem. On Tue, Nov 16, 2010 at 11:25 PM, Dennis Lee Bieber wrote: > On Tue, 16 Nov 2010 17:37:10 -0800, Brett Bowman > declaimed the following in gmane.comp.python.general: > > > > > And then I test the result: > > try: > > pdf_handle = open(outputFile, "rb") > > pdf_pypdf = PdfFileReader(pdf_handle) > > del pdf_pypdf > > del pdf_handle > > except Exception, e: > > return "Unable to open file: %s with error: %s" % (outputFile, > > str(e)) > > > You seem enamored of "del", which is something I've only used for > special purposes, and even then rarely -- binding a null object to the > name is just as effective for most uses. > >While the common Python does garbage collect objects when the > reference count goes to zero, there is no real guarantee of this. > >I'd replace that >del pdf_handle > whit >pdf_handle.close() > > -- >Wulfraed Dennis Lee Bieber AF6VN >wlfr...@ix.netcom.comHTTP://wlfraed.home.netcom.com/ > > -- > http://mail.python.org/mailman/listinfo/python-list > -- http://mail.python.org/mailman/listinfo/python-list
Subprocess Call works on Windows, but not Ubuntu
I ran into an interesting problem trying to spawn a subprocess, so I thought
I'd ask if the experts could explain it to me. I'm spawning a subprocess to
run "pdf2txt.py", which is a tool that is distributed with PDFminer to do
moderately advanced text-dumps of PDFs. Yet when I run the same code on my
two dev machines - one Win XP, the other Ubuntu 10.04 or 10.10 - it only
works on the former and not the later. And its not terribly complicated
code.
# Code Start
sp_line = 'python pdf2txt.py -p 1 -o %s "%s"' % ('temp.out', pdf_filename)
print sp_line
sp = subprocess.Popen(sp_line)
sp.wait()
with open('temp.out', 'r') as pdf_handle:
#Do stuff to read the file
The output from the print statements reads:
python pdf2txt.py -p 1 -o temp.out "Aarts et al (2009).pdf"
That command works on both systems when copied directly to the command-line,
and the python script it is a part of works on the Windows machine, but I
can't the script to work on Ubuntu for the life of me. What am I missing?
/b/
--
http://mail.python.org/mailman/listinfo/python-list
Re: Subprocess Call works on Windows, but not Ubuntu
Ah, that fixed it. Thank you.
On Tue, Nov 23, 2010 at 11:37 AM, Chris Rebert wrote:
> On Tue, Nov 23, 2010 at 11:28 AM, Brett Bowman wrote:
> > I ran into an interesting problem trying to spawn a subprocess, so I
> thought
> > I'd ask if the experts could explain it to me. I'm spawning a subprocess
> to
> > run "pdf2txt.py", which is a tool that is distributed with PDFminer to do
> > moderately advanced text-dumps of PDFs. Yet when I run the same code on
> my
> > two dev machines - one Win XP, the other Ubuntu 10.04 or 10.10 - it only
> > works on the former and not the later. And its not terribly complicated
> > code.
> > # Code Start
> > sp_line = 'python pdf2txt.py -p 1 -o %s "%s"' % ('temp.out',
> pdf_filename)
> > print sp_line
> > sp = subprocess.Popen(sp_line)
>
> > python pdf2txt.py -p 1 -o temp.out "Aarts et al (2009).pdf"
> > That command works on both systems when copied directly to the
> command-line,
> > and the python script it is a part of works on the Windows machine, but I
> > can't the script to work on Ubuntu for the life of me. What am I
> missing?
>
> Quoting the docs (for the Nth time; emphasis added):
> """
> On Unix, with shell=False (default): args should normally be a
> sequence. ***If a string is specified for args***, it will be used as
> the name or path of the program to execute; ***this will only work if
> the program is being given no arguments.***
> """ http://docs.python.org/library/subprocess.html#subprocess.Popen
>
> Fixed version:
> sp_args = ['python', 'pdf2txt.py', '-p', '1', '-o', 'temp.out',
> pdf_filename]
> sp = subprocess.Popen(sp_args)
>
> Cheers,
> Chris
> --
> http://blog.rebertia.com
>
--
http://mail.python.org/mailman/listinfo/python-list
Re: [Tutor] Which non SQL Database ?
On Sat, Dec 4, 2010 at 5:42 PM, Jorge Biquez wrote: > Newbie question. Sorry. If it isn't you're on the wrong list :) > training so no pressure on performance). One application will run as a > desktop one,under Windows, Linux, Macintosh, being able to update data, not > much, not complex, not many records. The important details here are: simple data, low-volume. I'm assuming this is single-user (as in, each instance of your application has it's own DB) > The second application, running behind > web pages, will do the same, Is this multiple users, each accessing the same DB? That really changes what you are looking for. If you are dealing with single-user, or only a few users, I'd say look into SQLite - It uses SQL syntax but doesn't run as a server and stores the database as a single file. It's great to use in small projects because the syntax is the same as larger projects, and you can replace with a full-blown multi-user SQL DB if you ever need to without having to rework everything. It's also very simple to use. I believe SQLite (sqlite3) is part of the core library in recent Python versions, or available as a package for older pythons. Berkeley DB is pretty much interchangeable with SQLite in terms of functionality. I much prefer SQLite. If your web application intends to have multiple users interacting with the same data, neither is probably a good fit. -- Brett Ritter / SwiftOne swift...@swiftone.org -- http://mail.python.org/mailman/listinfo/python-list
zlib.decompress fails, zlib.decompressobj succeeds - bug or feature?
Hi,
I sorry if this is a bad place to ask, but I wanted to find out if the
behavior I'm seeing is a bug.
I maintain scipy's matlab file readers, and I came across a zlib
compressed string that causes a zlib error on decompression, but only
with zlib.decompress, not zlib.decompressobj.
I saved the original compressed string as a binary file at
http://dl.dropbox.com/u/794947/mat.bin
Now if I do:
import zlib
data = open('mat.bin', 'rb').read()
out = zlib.decompress(data)
I get an error : Error -5 while decompressing data)
If instead I do this:
out = zlib.decompressobj().decompress(data)
I get a usable uncompressed string. I was expecting these two calls
to do the same thing. Is that expectation right? If not, is there
somewhere I could find out why?
Thanks a lot,
Matthew
--
http://mail.python.org/mailman/listinfo/python-list
Re: zlib.decompress fails, zlib.decompressobj succeeds - bug or feature?
Hi, Thanks for the reply. > > If instead I do this: > > > out = zlib.decompressobj().decompress(data) > > How about: > > d = zlib.decompressobj() > out = d.decompress(data) + d.flush() Do you mean, that you would then expect the decompressobj method to fail as well? But, no, d.flush() returns the empty string after decompressing ``data``. Thanks again, Matthew -- http://mail.python.org/mailman/listinfo/python-list
Re: zlib.decompress fails, zlib.decompressobj succeeds - bug or feature?
Hi, > > Do you mean, that you would then expect the decompressobj method to > > fail as well? > > Yes. > > > But, no, d.flush() returns the empty string after decompressing > > ``data``. > > Hmm, then it's a bug. Can you report it tohttp://bugs.python.org? I will - thanks for your advice, Matthew -- http://mail.python.org/mailman/listinfo/python-list
