Roundup Issue Tracker releases 0.8.5 (stable) and 0.9.0b1 (development)
Roundup is a simple-to-use and -install issue-tracking system with command-line, web and e-mail interfaces. It is based on the winning design from Ka-Ping Yee in the Software Carpentry Track design competition. The 0.8.5 stable release includes an Argentinian Spanish translation by Ramiro Morales and fixes some bugs: - Display of Multilinks where linked Class labelprop values are None - Fix references to the old * Registration Permissions - Fix missing merge of fix to sf bug 1177057 - Fix RDBMS indexer indexing UTF-8 words that encode to 30 chars - Handle invalidly-specified charsets in incoming email The 0.9.0b1 development release includes: - added imapServer.py script (sf patch 934567) - added date selection popup windows (thanks Marcus Priesch) - added Xapian indexer; replaces standard indexers if Xapian is available* - mailgw subject parsing has configurable levels of strictness - nosy messages may be sent individually to all recipients - remember where we came from when logging in (sf patch 1312889) *: unfortunately the latest release of Xapian (0.9.2) has a bug in the Python bindings which prevents this indexer from working, so it's disabled If you're upgrading from an older version of Roundup you *must* follow the Software Upgrade guidelines given in the maintenance documentation. Roundup requires python 2.3 or later for correct operation. To give Roundup a try, just download (see below), unpack and run:: python demo.py Source and documentation is available at the website: http://roundup.sourceforge.net/ Release Info (via download page): http://sourceforge.net/projects/roundup Mailing lists - the place to ask questions: http://sourceforge.net/mail/?group_id=31577 About Roundup = Roundup is a simple-to-use and -install issue-tracking system with command-line, web and e-mail interfaces. It is based on the winning design from Ka-Ping Yee in the Software Carpentry Track design competition. Note: Ping is not responsible for this project. The contact for this project is [EMAIL PROTECTED] Roundup manages a number of issues (with flexible properties such as description, priority, and so on) and provides the ability to: (a) submit new issues, (b) find and edit existing issues, and (c) discuss issues with other participants. The system will facilitate communication among the participants by managing discussions and notifying interested parties when issues are edited. One of the major design goals for Roundup that it be simple to get going. Roundup is therefore usable out of the box with any python 2.3+ installation. It doesn't even need to be installed to be operational, though a disutils-based install script is provided. It comes with two issue tracker templates (a classic bug/feature tracker and a minimal skeleton) and five database back-ends (anydbm, sqlite, metakit, mysql and postgresql). -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations.html
ABT 0.7
Initial release of ABT 0.7 under QPL license http://dev.artenum.com/projects/abt ABT automates the building of projects by executing the minimum set of commands to update the project like the famous Make. ABT is given a file, called the recipe (filename is abt-recipe.xml), that describes how the files that make up the project are related (how they are dependent upon one another) and how to update (build) those files. ABT checks the dates on the files to see if any need to be updated (when a target is older than one of its sources). If there are files that need to be updated, ABT executes the rule actions specified in the recipe for that purpose. ABT have also testing features that permit you to check if binaries you need to build your sources are present on the installation system. This checking phase is cached. Command execution are OS dependant so you can specify commands depending if you are running windows or unix system. ABT is the perfet tool for fast Jython/Java based application packaging and deployement because it may be integrated in the distribution and boostraped by the Jython interpreter. It's usefull for all kins of project and is not limited to Jython/Java projects. ABT is pure Python 2.1 written and so is interpretable with Jython. It includes a basic Makefile2recipe converter helping you migrating from Makefiles. Contact Maxime Biais : maxime.biais (AT) artenum.com -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations.html
py2exe 0.6.3 released
py2exe 0.6.3 released = py2exe is a Python distutils extension which converts Python scripts into executable Windows programs, able to run without requiring a Python installation. Console and Windows (GUI) applications, Windows NT services, exe and dll COM servers are supported. Changes in 0.6.3: * First release assembled by py2exe's new maintainer, Jimmy Retzlaff. Code changes in this release are from Thomas Heller and Gordon Scott. * The dll-excludes option is now available on the command line. It was only possible to specify that in the options argument to the setup function before. The dll-excludes option can now be used to filter out dlls like msvcr71.dll or even w9xpopen.exe. * Fix from Gordon Scott: py2exe crashed copying extension modules in packages. Changes in 0.6.2: * Several important bugfixes: - bundled extensions in packages did not work correctly, this made the wxPython single-file sample fail with newer wxPython versions. - occasionally dlls/pyds were loaded twice, with very strange effects. - the source distribution was not complete. - it is now possible to build a debug version of py2exe. Changes in 0.6.1: * py2exe can now bundle binary extensions and dlls into the library-archive or the executable itself. This allows to finally build real single-file executables. The bundled dlls and pyds are loaded at runtime by some special code that emulates the Windows LoadLibrary function - they are never unpacked to the file system. This part of the code is distributed under the MPL 1.1, so this license is now pulled in by py2exe. * By default py2exe now includes the codecs module and the encodings package. * Several other fixes. Homepage: http://www.py2exe.org Download from the usual location: http://sourceforge.net/project/showfiles.php?group_id=15583 Enjoy, Jimmy -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations.html
BayPIGgies: October 13, 7:30pm (IronPort)
The next meeting of BayPIGgies will be Thurs, October 13 at 7:30pm at IronPort. Tim Thompson will describe and demonstrate the interaction between Burning Man and Python using two applications, Radio Free Quasar and Ergo. BayPIGgies meetings alternate between IronPort (San Bruno, California) and Google (Mountain View, California). For more information and directions, see http://www.baypiggies.net/ Before the meeting, we sometimes meet at 6pm for dinner. Discussion of dinner plans is handled on the BayPIGgies mailing list. Advance notice: We've got some options on the plate for November 10 but haven't settled anything yet. Please send e-mail to [EMAIL PROTECTED] if you want to suggest an agenda (or volunteer to give a presentation). The meeting agenda for December 8 has been set. -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ The way to build large Python applications is to componentize and loosely-couple the hell out of everything. -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations.html
Re: [Info] PEP 308 accepted - new conditional expressions
On Monday 03 October 2005 03:48 am, Volker Grabsch wrote: Fredrik Lundh wrote: /... snip comment that the natural order is C, X, Y and that programmers that care about readable code will probably want to be extremely careful with this new feature .../ That's also my opinion, but OTOH, Guido's syntax is more close to the syntax of list comprehensions. GvR's syntax has the advantage of making grammatical sense in English (i.e. reading it as written pretty much makes sense). -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com -- http://mail.python.org/mailman/listinfo/python-list
where to find information about errors/exceptions in socket.py
Version of python: 2.4 O/S: Win2K I will be writing some python scripts to do some client-side programming that involves socket.py. I expect that I will be making calls to the following methods/functions: connect_ex() setsockopt() sendall() recv() close() Where can one find information about whether the functions/methods above return error codes that provide some indication as to whether the function/method succeeded? Is there an exception class for handling exceptions raised in socket.py? If so, where can one find information about it? I consulted the docstrings and didn't find much about return codes or exception classes. Also looked at the Lutz Programming Python text...it devotes several pages to socket programming, but I didn't observe much with regard to error/exception handling. -- http://mail.python.org/mailman/listinfo/python-list
py2exe 0.6.3 released
py2exe 0.6.3 released = py2exe is a Python distutils extension which converts Python scripts into executable Windows programs, able to run without requiring a Python installation. Console and Windows (GUI) applications, Windows NT services, exe and dll COM servers are supported. Changes in 0.6.3: * First release assembled by py2exe's new maintainer, Jimmy Retzlaff. Code changes in this release are from Thomas Heller and Gordon Scott. * The dll-excludes option is now available on the command line. It was only possible to specify that in the options argument to the setup function before. The dll-excludes option can now be used to filter out dlls like msvcr71.dll or even w9xpopen.exe. * Fix from Gordon Scott: py2exe crashed copying extension modules in packages. Changes in 0.6.2: * Several important bugfixes: - bundled extensions in packages did not work correctly, this made the wxPython single-file sample fail with newer wxPython versions. - occasionally dlls/pyds were loaded twice, with very strange effects. - the source distribution was not complete. - it is now possible to build a debug version of py2exe. Changes in 0.6.1: * py2exe can now bundle binary extensions and dlls into the library-archive or the executable itself. This allows to finally build real single-file executables. The bundled dlls and pyds are loaded at runtime by some special code that emulates the Windows LoadLibrary function - they are never unpacked to the file system. This part of the code is distributed under the MPL 1.1, so this license is now pulled in by py2exe. * By default py2exe now includes the codecs module and the encodings package. * Several other fixes. Homepage: http://www.py2exe.org Download from the usual location: http://sourceforge.net/project/showfiles.php?group_id=15583 Enjoy, Jimmy -- http://mail.python.org/mailman/listinfo/python-list
os.access with wildcards
i'd like to use
os.access(path,mode)
where path may contain linux style wildcards.
i've failed so far.
my workaround is the bash command.
os.system('[ -e %s ]' % fn )
any suggestions?
--
http://mail.python.org/mailman/listinfo/python-list
Re: PyObject_New
Jeremy Moles wrote:
[...] What I'm trying
now is the following:
PyObject* obj = _PyObject_New(PyType_MyType);
obj = PyObject_Init(obj, PyType_MyType);
...
return obj;
When obj gets back to the interpreter, Python sees it (or rather, it's
__repr__) in accordance with what it should be. However, any attempt
to USE the object results in a segfault. I feel my problem is simply
that I'm not allocating obj correctly in the C++ function.
If anyone has any advice, I would really appreciate it.
When I looked for info on this, I didn't find any good documentation,
either.
I'm currently using code like the following in pysqlite
(http://initd.org/tracker/pysqlite/browser/pysqlite/trunk/src/connection.c?rev=154):
126 if (factory == NULL) {
127 factory = (PyObject*)CursorType;
128 }
129
130 cursor = PyObject_CallFunction(factory, O, self);
So, basically I'm just calling the type like any other callable object.
I don't remember if there was a reason why I didn't use
PyObject_CallObject instead, at the time ...
In any case, this approach worked fine for me.
-- Gerhard
--
http://mail.python.org/mailman/listinfo/python-list
Re: os.access with wildcards
mike wrote: i'd like to use os.access(path,mode) where path may contain linux style wildcards. os.access(glob.glob(path), mode) -- http://mail.python.org/mailman/listinfo/python-list
Re: When someone from Britain speaks, Americans hear a British accent...
On Fri, 07 Oct 2005 00:33:43 -, Grant Edwards [EMAIL PROTECTED] wrote: On 2005-10-06, DaveM [EMAIL PROTECTED] wrote: Frankly, I can't watch Shakespeare or movies like the full monty or trainspotting because I can't understand a damn word they say. British talk sounds like gibberish to me for the most part. Not just you. It always amuses me in trips to the US that British voices (outside of the movies) are often subtitled, while first-generation Americans whose English is. um, limited, are not. What?!? I've never seen a British voice (inside or outside of the movies) subtitled -- with the exception of one of a nightclub scenes in one movie (I think it was Trainspotting) where the dialog was inaudible because of the music. I noticed this watching news footage rather than imported shows. I haven't seen 'Trainspotting', but I have seen Scottish accents subtitled (unnecessarily) on English TV, to understandable anger across the border - so this isn't uniquely a US phenomenon, to be fair. snip For example: In British English one uses a plural verb when the subject consists of more than one person. Sports teams, government departments, states, corporations etc. are grammatically plural. In American, the verb agrees with the word that is the subject, not how many people are denoted by that word. In sports (thats sport for you Brits): Yes. American: Minnesota is behind 7-0. The Vikings are behind 7-0. British: Minnesota are behind 7-0. The Vikings are behind 7-0. True. In politics: American: The war department has decided to cancel the program. British: The war department have decided to cancel the program. Not sure about this one. They may be used interchangeably as neither strikes me as sounding odd. DaveM -- http://mail.python.org/mailman/listinfo/python-list
RE: Build spoofed IP packets
See scapy.py I've completed windows support at this time and am currently testing it, working out some bugs. If you want a copy just ask. I need some testers. It can do almost any packet transmissions you want. (google it) Z -- http://mail.python.org/mailman/listinfo/python-list
Re: Merging sorted lists/iterators/generators into one stream of values...
Ok, that one looks more sleak than what I came up with. Couple of things I learn from your solution, please correct me if I misunderstood something: 1. list containing other lists will sort itself based on first element on lists inside ? 2. sort(), pop() is not costly operations Other than that you seem to not use the cmp operator but that's easily fixed. This one looks much better than mine, here's what I came up with: def merge_sorted(iterables, comparer=None): Generator that will take a list of iterables/generators that is individually sorted, and then produce values in a sorted order by taking the lowest value from each source each call. @param iterables: List of iterables/generators to retrieve values from @type iterables: List of iterables/generators @param comparer: Optional fn(v1, v2) function that can compare two values, should return 0 if v1v2, 0 if v1v2 and ==0 if v1==v2. @type comparer: function-object, example: lambda x, y: x-y @note: The list of iterables can actually be anything that produces a list of iterables, so you can use a function that yields lists for instance. # First convert whatever we're given into a list of sources iterables = [iterable for iterable in iterables] # This series of if-statements will determine how many sources we have and work out sub-problems # that are manageable. if len(iterables) != 2: if len(iterables) == 0: # List, but no sources pass elif len(iterables) == 1: # Only 1 source, just return its contents for value in iterables[0]: yield value elif len(iterables) == 3: # 3 sources, sub-divide into 0 -- (1, 2) left_iterable = iterables[0] right_iterable = merge_sorted([iterables[1], iterables[2]], comparer) for value in merge_sorted([left_iterable, right_iterable], comparer): yield value elif len(iterables) == 4: # 4 sources, sub-divide into (0, 1) -- (2, 3) left_iterable = merge_sorted([iterables[0], iterables[1]], comparer) right_iterable = merge_sorted([iterables[2], iterables[3]], comparer) for value in merge_sorted((left_iterable, right_iterable), comparer): yield value elif len(iterables) 4: # 4 sources, sub-divide into (0, 1) -- (2, ...) left_iterable = merge_sorted([iterables[0], iterables[1]], comparer) right_iterable = merge_sorted(iterables[2:], comparer) for value in merge_sorted((left_iterable, right_iterable), comparer): yield value raise StopIteration # The method will only get here if there is only two sources, which is an easy case to handle i1 = iter(iterables[0]) i2 = iter(iterables[1]) # Grab the first two values from the two sources, if possible try: v1 = i1.next() has_v1 = True except StopIteration: has_v1 = False try: v2 = i2.next() has_v2 = True except StopIteration: has_v2 = False # As long as we got values from both generates/iterators/whatever, compare and yield the lowest of the # two, and then get the next value from the corresponding source while has_v1 and has_v2: # Work out which of v1 and v2 comes first if comparer is not None: comp = comparer(v1, v2) if comp = 0: yield_v1 = True else: yield_v1 = False else: if v1 = v2: yield_v1 = True else: yield_v1 = False # Yield the next value, then grab a new value from the corresponding source if yield_v1: yield v1 try: v1 = i1.next() except StopIteration: has_v1 = False else: yield v2 try: v2 = i2.next() except StopIteration: has_v2 = False # When we get here, we got 3 possibilities: # 1. has_v1 == True, has_v2 == False -- yield rest of v1/i1 and just exit on StopIteration exception # 2. has_v1 == False, has_v1 == True -- yield rest of v2/i2 and just exit on StopIteration exception # 3. has_v1 == has_v2 == False -- while-loops will skip, function falls off the end while has_v1: yield v1 v1 = i1.next() while has_v2: yield v2 v2 = i2.next() -- http://mail.python.org/mailman/listinfo/python-list
Re: os.access with wildcards
thanks Leif. poor question on my part.
I had been using
glob.glob(path)==[]
and was looking for something more readable, hence
os.system('[ -e %s ]' % path )
but that doesn't seem like a good idiom for crossplatform.
I thought there may either be a way to escape the wildcards, or an
alternative to os.access, or
any othr ideas?
--
http://mail.python.org/mailman/listinfo/python-list
Re: os.access with wildcards
thanks Leif. poor question on my part.
I had been using
glob.glob(path)==[]
and was looking for something more readable, hence
os.system('[ -e %s ]' % path )
but that doesn't seem like a good idiom for crossplatform.
I thought there may either be a way to escape the wildcards, or an
alternative to os.access, or
any other ideas?
--
http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Op 2005-10-06, Diez B. Roggisch schreef [EMAIL PROTECTED]: Suppose we have a typesystem which has the type ANY, which would mean such an object could be any type. You could then have homogenous lists in the sense that all elements should be of the same declared type and at the same time mix all kind of type in a particular list, just as python does. The you have JAVA Object or C void*. Which cause all kinds of runtime troubles because they essentially circumvene the typechecking! Why do you call this a JAVA Object or C void*? Why don't you call it a PYTHON object. It is this kind of reaction that IMO tells most opponents can't think outside the typesystems they have already seen and project the problems with those type systems on what would happen with python should it acquire a type system. So how would this limit python. The limitation is that in static languages I must _know_ what type to cast such an ANY, before calling anything on it. Otherwise its useless. even though ususally the contents of a list share some common behaviour. And that exactly is the key point here: in a statically typed world, that common behaviour must have been extracted and made explicit. Would my suggestion be classified as a statically typed world? See above. Your answer tells more about you then about my suggestion. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: non descriptive error
On Thursday 06 October 2005 11:57 pm, Timothy Smith wrote: i try to run my app and i get this %python DutyShift.py error thats it. thats the error. mya pp was previously working, and i did make some fairly large changes to it, but i'd expect a more descriptive message then just error. anyidea where i need to start looking? By looking at the source code for DutyShift.py? -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com -- http://mail.python.org/mailman/listinfo/python-list
Re: where to find information about errors/exceptions in socket.py
[EMAIL PROTECTED] wrote: Version of python: 2.4 O/S: Win2K I will be writing some python scripts to do some client-side programming that involves socket.py. I expect that I will be making calls to the following methods/functions: connect_ex() setsockopt() sendall() recv() close() Where can one find information about whether the functions/methods above return error codes that provide some indication as to whether the function/method succeeded? Is there an exception class for handling exceptions raised in socket.py? If so, where can one find information about it? I consulted the docstrings and didn't find much about return codes or exception classes. Also looked at the Lutz Programming Python text...it devotes several pages to socket programming, but I didn't observe much with regard to error/exception handling. I'd suggest reading the documentation myself: http://docs.python.org/lib/module-socket.html regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC www.holdenweb.com PyCon TX 2006 www.python.org/pycon/ -- http://mail.python.org/mailman/listinfo/python-list
Can't extend function type
Oh well. I had wanted to be able to define two functions f and g, and have f*g be the composition of f and g. func_type = type(lambda: None) class composable_function(func_type): ... def __mult__(f,g): ... def c(*args, **kw): ... return f(g(*args, **kw)) ... return c ... Traceback (most recent call last): File stdin, line 1, in ? TypeError: Error when calling the metaclass bases type 'function' is not an acceptable base type Seems like a wart to me. -- http://mail.python.org/mailman/listinfo/python-list
Re: non descriptive error
You should tell us more about DutyShift.py, without the code it is very difficult for other people to guess what's going on. -- http://mail.python.org/mailman/listinfo/python-list
ANN: MathDOM 0.5.0 - MathML in Python
Hi everyone, MathDOM 0.5 is ready for download from SourceForge. http://mathdom.sourceforge.net/ MathDOM is a set of Python modules (using PyXML and pyparsing) that import mathematical terms as a Content MathML DOM. It currently parses MathML and literal infix terms into a DOM and writes out MathML and literal infix, prefix, postfix or Python terms. The DOM elements are enhanced by domain specific methods that make using the DOM a little easier. You can call it the shortest way between different term representations and an enhanced Content MathML DOM. Ever noticed the annoying differences between terms in different programming languages? Build your application around the DOM and stop careing about the term representation that users prefer or that your machine can execute. If you need a different representation, add a converter, but don't change the model. Literal terms are connected through an intermediate AST step that makes writing converters for Python/SQL/yourfavorite easier. ** New in 0.5.0 ** This release features a completely new API for term I/O. It uses dictionary-like classes for registering input/output converters. This makes it easier to extend the package with custom converters. It also means that 'old' code will break, but since the package is farely recent, I hope that this will not make its users too much trouble. If the new API is accepted, I will try to keep it stable in further releases. The examples were updated to show how the new API is used. Have fun, Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: non descriptive error
Timothy Smith wrote: i try to run my app and i get this %python DutyShift.py error thats it. thats the error. mya pp was previously working, and i did make some fairly large changes to it, but i'd expect a more descriptive message then just error. anyidea where i need to start looking? I would look inside *your* program! I don't ever remember Python producing any message so terse and unhelpful. A way to check this would be to run python interactively and enter the statement import DutyShift though this won't necessarily run all the logic that gets run by your command. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC www.holdenweb.com PyCon TX 2006 www.python.org/pycon/ -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Antoon Pardon wrote: Op 2005-10-06, Diez B. Roggisch schreef [EMAIL PROTECTED]: Suppose we have a typesystem which has the type ANY, which would mean such an object could be any type. You could then have homogenous lists in the sense that all elements should be of the same declared type and at the same time mix all kind of type in a particular list, just as python does. The you have JAVA Object or C void*. Which cause all kinds of runtime troubles because they essentially circumvene the typechecking! Why do you call this a JAVA Object or C void*? Why don't you call it a PYTHON object. It is this kind of reaction that IMO tells most opponents can't think outside the typesystems they have already seen and project the problems with those type systems on what would happen with python should it acquire a type system. [sigh]. No, it's just you being you. Diez' intention seemed fairly clear to me: he is pointing out that strongly-typed systems invariably fall back on generic declarations when they want to allow objects of any type (which, it seems to me, is what you were proposing as well). In other words, you want Python to be strongly-typed, but sometimes you want to allow a reference to be to any object whatsoever. In which case you can't possibly do any sensible type-checking on it, so this new Python+ or whatever you want to call it will suffer from the same shortcomings that C++ and java do, which is to say type checking can't possibly do anything useful when the acceptable type of a reference is specified as ANY. So how would this limit python. The limitation is that in static languages I must _know_ what type to cast such an ANY, before calling anything on it. Otherwise its useless. even though ususally the contents of a list share some common behaviour. And that exactly is the key point here: in a statically typed world, that common behaviour must have been extracted and made explicit. Would my suggestion be classified as a statically typed world? See above. Your answer tells more about you then about my suggestion. Damn, I've been keeping away from this thread lest my exasperation lead me to inappropriate behaviour. Is there any statement that you *won't* argue about? leaving-the-(hopefully)-last-word-to-you-ly y'rs - steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC www.holdenweb.com PyCon TX 2006 www.python.org/pycon/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Python, alligator kill each other
infidel wrote: A 13-foot Burmese python recently burst after it apparently tried to swallow a live 6-foot alligator whole, authorities said. An allegory telling how Python the language really ought to stay slim and lean and not get bloated by incorporating lots of features from other languages? -- http://mail.python.org/mailman/listinfo/python-list
Re: PyObject_New
Jeremy Moles wrote: PyObject* obj = _PyObject_New(PyType_MyType); obj = PyObject_Init(obj, PyType_MyType); ... return obj; The call to PyObject_Init is redundant: _PyObject_New is malloc+init. However, this shouldn't cause any crashes (except in the debug build). PyObject_Init is documented as Initialize a newly-allocated object op with its type and initial reference. Returns the initialized object. If type indicates that the object participates in the cyclic garbage detector, it is added to the detector's set of observed objects. Other fields of the object are not affected. [I don't know where the mentioning of GC comes from - it appears to be incorrect] When obj gets back to the interpreter, Python sees it (or rather, it's __repr__) in accordance with what it should be. However, any attempt to USE the object results in a segfault. I feel my problem is simply that I'm not allocating obj correctly in the C++ function. It doesn't crash because of the allocation - this code is correct. However, it is also incomplete: none of the state of the new object gets initialized in the fragment you are showing. So it likely crashes because the members of the object are stray pointers or some such, and accessing them causes a crash. Regards, Martin -- http://mail.python.org/mailman/listinfo/python-list
Re: Controlling who can run an executable
Cigar wrote: What I want: - the simplest thing that could possibly work! A splash screen that informs the user that it's confidential data, and that unauthorized use will lead to prosecution? Besides, I think it's not the program you need to protect, but the data. Think about that. Who cares about a hardware dongle if they can access the information you're trying to protect in notepad or via ODBC and MS query etc. She's as vulnerable if someone prints out a listing of the clients and takes that, as if someone copies the program. If you have the ability to generate lists of data, you might not want that feature to be accessible to normal users. Finally, there's another nice trick that you can do, now that most computers are hooked up on the net. Make the program report when it's being used. The easiest way might be to make it send an email, but I'm not quite sure how you set it up to do that on a windows box without asking the data-thief about email settings. Virus-programs obviously do this, so it can't be too hard. (Actually, to do something in your program that will alert anti-virus programs might be a good protection!) You could also make the program phone home via a socket etc, but that requires a server that can be reached on the net. But as others have said, you should make this a client-server app, and make sure the server is physically protected, difficult to break into (a DOS box or an old MAC?) and only serve the right kind of data to an authenticated user connected locally. -- http://mail.python.org/mailman/listinfo/python-list
Re: semi-newbie module namespace confusion
[EMAIL PROTECTED] wrote:
The main jist of the problem is that I'm trying add data from one
module to a list and a dictionary in another module, and it doesn't
seem to stick over there.
It's probably best to avoid any circular depentencies, but as
long as you make sure you really use your modules as modules,
and not one of them aas a main prorgam, I think it should work.
$ cat a.py
import b
def set_b(n):
b.b=n
$ cat b.py
import a
def set_a(n):
a.a=n
$ python
Python 2.2.3 (#1, Feb 2 2005, 12:20:51)
[GCC 3.2.3 20030502 (Red Hat Linux 3.2.3-49)] on linux2
Type help, copyright, credits or license for more information.
import a,b
a.set_b('B')
b.set_a('A')
a.a
'A'
b.b
'B'
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python, alligator kill each other
infidel wrote: By Denise Kalette Associated Press MIAMI - The alligator has some foreign competition at the top of the Everglades food chain, and the results of the struggle are horror-movie messy. A 13-foot Burmese python recently burst after it apparently tried to swallow a live 6-foot alligator whole, authorities said. ... ... It is unknown how many pythons are competing with the thousands of alligators in the Everglades, but at least 150 have been captured in the past two years ... When I read the title 'Python vs. Alligator' on Slashdot, I thought it was about some comparison between Python and an unknown-to-me programming language Alligator. -- If I have been able to see further, it was only because I stood on the shoulders of giants. -- Isaac Newton Roel Schroeven -- http://mail.python.org/mailman/listinfo/python-list
Re: dcop module under Python 2.4
[EMAIL PROTECTED] wrote: Hi all, at the end I upgraded to 2.4, but now I am not able to load dcop module (part of the Python-KDE3 bindings). Any help? Install PyKDE for 2.4 Diez -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Steve Holden [EMAIL PROTECTED] writes: In other words, you want Python to be strongly-typed, but sometimes you want to allow a reference to be to any object whatsoever. In which case you can't possibly do any sensible type-checking on it, so this new Python+ or whatever you want to call it will suffer from the same shortcomings that C++ and java do, which is to say type checking can't possibly do anything useful when the acceptable type of a reference is specified as ANY. Let's see if I understand what you're saying: C and Java: you get useful type checking except when you declare a reference as type ANY. This is a shortcoming compared to: Python: where you get no useful type checking at all. That is not very convincing logic. -- http://mail.python.org/mailman/listinfo/python-list
Re: When someone from Britain speaks, Americans hear a British accent...
DaveM wrote: On Fri, 07 Oct 2005 00:33:43 -, Grant Edwards [EMAIL PROTECTED] wrote: [...] For example: In British English one uses a plural verb when the subject consists of more than one person. Sports teams, government departments, states, corporations etc. are grammatically plural. In American, the verb agrees with the word that is the subject, not how many people are denoted by that word. In sports (thats sport for you Brits): OK, so how do you account for the execresence That will give you a savings of 20%, which usage is common in America? There aren't any universal rules, except possibly British people speak English while Americans don't. Nowadays relatively few people on either side of the Atlantic even know the difference between a collective noun and a plural, so there's little hope of them being able to correctly apply any rule there might be (and yes, I split that infinitive just to annoy any pedants who may be reading). Yes. American: Minnesota is behind 7-0. The Vikings are behind 7-0. British: Minnesota are behind 7-0. The Vikings are behind 7-0. True. In politics: American: The war department has decided to cancel the program. British: The war department have decided to cancel the program. Not sure about this one. They may be used interchangeably as neither strikes me as sounding odd. Then again, there's room for infinite disagreement about these topics. I mentioned a while ago that I disliked the English on a bumper sticker I liked, which read Some village in Texas is missing their idiot. Several people defended this, saying that a village could use the plural possessive their. I personally found it odd (and essentially non-grammatical) not because either the singular or plural forms should be mandated but because this one manages to mix them up. So Some village in Texas are missing their idiot would be better (though it sounds like the kind of thing only the idiot alluded to would say), while my preferred choice would be Some village in Texas is missing its idiot. Then again, what can you expect from a country whose leader pronounces nuclear as though it were spelled nucular? I suppose it's only a matter of time before they change the spelling just like they did with aluminium. tongue-in-cheek-ly y'rs - steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC www.holdenweb.com PyCon TX 2006 www.python.org/pycon/ -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Paul Rubin wrote: Brian Quinlan [EMAIL PROTECTED] writes: Without a clear idea of the nature of the proposal, it is impossible to assess it's costs and benefits. So could a proponent of optional declarations please provide a more clear proposal? There is no proposal on the table. There's a discussion of how this stuff can work, and whether it's useful. As for how the compiler deals with imported modules, see for example Common Lisp or Haskell or ML--how do they do it? Except that you are providing neither useful input on how it could work nor on whether it would be useful. All you are doing is telling people to do research on other languages (that resumably do things in a way more to your liking). In conclusion, this thread is unlikely to make any useful progress. Cheers, Brian -- http://mail.python.org/mailman/listinfo/python-list
Re: Can't extend function type
Paul Rubin wrote: Oh well. I had wanted to be able to define two functions f and g, and have f*g be the composition of f and g. func_type = type(lambda: None) class composable_function(func_type): ... def __mult__(f,g): ... def c(*args, **kw): ... return f(g(*args, **kw)) ... return c ... Traceback (most recent call last): File stdin, line 1, in ? TypeError: Error when calling the metaclass bases type 'function' is not an acceptable base type Seems like a wart to me. Well - function inheritance is not known so far in python - and in no other language I know. How do you expect to create f and g, even if above construct would work? Basdically you want __mult__ being part of f or g when python encounters something like this f * g But then how did you plan to declare f? def f(composable_function)(x): pass obviously won't work. So the only way to achieve this with current semantics is to make f anf g objects with a call methods. In that very moment, you're done - as extending from object is no problem :) class ComposeableFunction(object): def __call__(self, *args, **kwargs): return self.second(self.first(*args, **kwargs)) def __mul__(self, other): nc = ComposeableFunction() nc.first = other nc.second = self return nc class f(ComposeableFunction): def __call__(self, x): return x * 2 class g(ComposeableFunction): def __call__(self, x): return x + 2 f = f() g = g() print f(4) print g(4) print (f*g)(4) Diez -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Paul Rubin wrote: Steve Holden [EMAIL PROTECTED] writes: In other words, you want Python to be strongly-typed, but sometimes you want to allow a reference to be to any object whatsoever. In which case you can't possibly do any sensible type-checking on it, so this new Python+ or whatever you want to call it will suffer from the same shortcomings that C++ and java do, which is to say type checking can't possibly do anything useful when the acceptable type of a reference is specified as ANY. Let's see if I understand what you're saying: C and Java: you get useful type checking except when you declare a reference as type ANY. This is a shortcoming compared to: Python: where you get no useful type checking at all. That is not very convincing logic. As we say in Yorkshire, There's none as thick as them that wants to be. Let's try to get this in context. Antoon: Suppose we have a typesystem which has the type ANY, which would mean such an object could be any type. You could then have homogenous lists in the sense that all elements should be of the same declared type and at the same time mix all kind of type in a particular list, just as python does. Diez: The you have JAVA Object or C void*. Which cause all kinds of runtime troubles because they essentially circumvene the typechecking! Antoon: Why do you call this a JAVA Object or C void*? Why don't you call it a PYTHON object. It is this kind of reaction that IMO tells most opponents can't think outside the typesystems they have already seen and project the problems with those type systems on what would happen with python should it acquire a type system. Me: Diez' intention seemed fairly clear to me: he is pointing out that strongly-typed systems invariably fall back on generic declarations when they want to allow objects of any type (which, it seems to me, is what you were proposing as well). You: C and Java: you get useful type checking except when you declare a reference as type ANY. This is a shortcoming compared to: Python: where you get no useful type checking at all. The points that have repeatedly been made are: 1. That even the strict typings required by languages like Java and C++ actually end up getting in the way when the pragmatic requirements of real-world problems have to be taken into account. 2. That the benefits of declarations are overstated by many of their proponents. 3. That Python as it is today allows the dynamic creation of names, which are therefore inherently not available for declaration. On existing evidence it's extremely unlikely that this post will end the thread, but I certainly wish *something* would. Unfortunately I seem to have become part of the problem in that respect :-) regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC www.holdenweb.com PyCon TX 2006 www.python.org/pycon/ -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Brian Quinlan [EMAIL PROTECTED] writes: There is no proposal on the table. There's a discussion of how this stuff can work, and whether it's useful. As for how the compiler deals with imported modules, see for example Common Lisp or Haskell or ML--how do they do it? Except that you are providing neither useful input on how it could work nor on whether it would be useful. All you are doing is telling people to do research on other languages (that resumably do things in a way more to your liking). Nah. I just see the import statement as a solved problem. Do it the same way those other languages do. -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Why do you call this a JAVA Object or C void*? Why don't you call it a PYTHON object. It is this kind of reaction that IMO tells most opponents can't think outside the typesystems they have already seen and project the problems with those type systems on what would happen with python should it acquire a type system. Well, because maybe I wanted you to give you an example of languages that are statically typed and have such an any construct - that, by the way, is not a piece of inguine imagination of yours, but has been thought of before, e.g. CORBA (and called there any, too)? It makes no sense putting python into that context - as it is _not_ statically typed. Which you should know, after discussing this very subject way too long. Would my suggestion be classified as a statically typed world? See above. Your answer tells more about you then about my suggestion. Your answer tells us something too: Just because you don't know anything about typechecking does not mean that you are in the position to make assumptions on how things could work if the people who know stuff wouldn't be so stupid. That's like saying cars can't fly because the stupid engineers lack my sense of imagination. Just blathering about the possibility of some super-duper-typechecker and countering criticism or being told about problems in that domain by making bold statements that this sure could work - provide us with an implementation. Or maybe - just maybe - you could sit back and think about the fact that lots of people who are way cleverer than you and me have been working on this subject, and so far haven't found a way. Which doesn't necessarily mean that there is no way - but certainly its hard, theory-laden work and won't emerge in a NG discussion by some snide remarks of either you or anybody else. Diez -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Paul Rubin wrote: Steve Holden [EMAIL PROTECTED] writes: In other words, you want Python to be strongly-typed, but sometimes you want to allow a reference to be to any object whatsoever. In which case you can't possibly do any sensible type-checking on it, so this new Python+ or whatever you want to call it will suffer from the same shortcomings that C++ and java do, which is to say type checking can't possibly do anything useful when the acceptable type of a reference is specified as ANY. Let's see if I understand what you're saying: C and Java: you get useful type checking except when you declare a reference as type ANY. This is a shortcoming compared to: Python: where you get no useful type checking at all. That is not very convincing logic. No, he said that this typechecking wouldn't make sense in the case of ANY being used. And the plethorea of ClassCastExceptions and Segfault proves the point :) Diez -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Paul Rubin wrote: Let's see if I understand what you're saying: C and Java: you get useful type checking except when you declare a reference as type ANY. This is a shortcoming compared to: Python: where you get no useful type checking at all. That is not very convincing logic. It's started to get very misleading - Python gives you plenty of type-checking, as we all know, just not at compile-time. Also comparing Python to C/Java as you have done is not very appropriate unless you want Python to have the same sort of compile times as C and Java do. I think you're doing a small disservice to respond to Steve when not acknowledging the context of the thread, where Diez was explaining that the system used in ML would not work in Python, then Antoon made a suggestion that would fix that particular problem but make others worse. I'm not convinced that the Java route - where you type out lengthy type declarations to get some compile-time typechecking which you usually end up having to bypass later anyway - is at all beneficial, at least not in the context of Python. I can't ever remember a time when I thought type checking really saved me from a bug there when using C/C++/Java, but I _can_ remember many times where I've had to consider which cast or conversion to use, or had to write another overloaded function to accommodate a similar-but-different type, or debug a complex template message, or add a superfluous base class or interface, all just to get the kind of genericity that Python gives for free. And it's no good saying that variable declarations will be optional, because as soon as these statically-typed variables enter the standard library, every Python programmer will have to take these considerations on board when writing their code, whether we want to use them or not. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: [Info] PEP 308 accepted - new conditional expressions
As mentioned earlier only a dictator can make such decisions and of course as with many dictatorships the wrong decision is often made. There's no such thing as a benevolent dictatorship. -- Robin Becker -- http://mail.python.org/mailman/listinfo/python-list
Re: os.access with wildcards
Leif K-Brooks wrote: os.access(path,mode) where path may contain linux style wildcards. os.access(glob.glob(path), mode) Traceback (most recent call last): File stdin, line 1, in ? TypeError: access() argument 1 must be string, not list it's not clear from the OP if he wants [os.access(file, mode) for file in glob.glob(path))] os.access(glob.glob(path)[0], mode) or, most likely, simply if glob.glob(path): ... some matching file exists ... /F -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Ben Sizer [EMAIL PROTECTED] wrote: It's started to get very misleading - Python gives you plenty of type-checking, as we all know, just not at compile-time. There's more to it than just that. Python's type checking is not just not done at compile time, it's done as late in run time as possible. One might call it just-in-time type checking. It's not hard to imagine a Python-like language which included (perhaps optional) variable declarations. A declaration would essentially be an assertion which was checked after each assignment to that name. So, you could write: int i = 5 i = 5.6 and the second statement would throw TypeError. This would give you C++/Java style type safety, but it still wouldn't be compile time. Perhaps a better way to describe it is that the checking isn't an is-a assertion, but an acts-like assertion (sort of like Java's interfaces). To take an example, in the function: def first3(y): if len(y) 3: return y return y[0:3] all I really need from the argument is that I can call len() on it and it can be sliced. An easy way to describe this would be to say that y must be a sequence, but that's not strictly accurate, since I can easily declare my own class which meets those requirements without being a subclass of sequence (even ignoring for the moment that 'sequence', while talked about in the documentation, doesn't actually exist as something you can subclass). -- http://mail.python.org/mailman/listinfo/python-list
Re: non descriptive error
Timothy Smith wrote: i try to run my app and i get this %python DutyShift.py error thats it. thats the error. mya pp was previously working, and i did make some fairly large changes to it, but i'd expect a more descriptive message then just error. anyidea where i need to start looking? It seems to me, like a result of a print statement, exexcuted somewhere (maybe in the except: clause). You may look for lines similar to: print error Tomasz Lisowski -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Op 2005-10-07, Steve Holden schreef [EMAIL PROTECTED]: Antoon Pardon wrote: Op 2005-10-06, Diez B. Roggisch schreef [EMAIL PROTECTED]: Suppose we have a typesystem which has the type ANY, which would mean such an object could be any type. You could then have homogenous lists in the sense that all elements should be of the same declared type and at the same time mix all kind of type in a particular list, just as python does. The you have JAVA Object or C void*. Which cause all kinds of runtime troubles because they essentially circumvene the typechecking! Why do you call this a JAVA Object or C void*? Why don't you call it a PYTHON object. It is this kind of reaction that IMO tells most opponents can't think outside the typesystems they have already seen and project the problems with those type systems on what would happen with python should it acquire a type system. [sigh]. No, it's just you being you. Diez' intention seemed fairly clear to me: he is pointing out that strongly-typed systems invariably fall back on generic declarations when they want to allow objects of any type (which, it seems to me, is what you were proposing as well). It is not about falling back on generic declarartion, it is about how such object will be treated. Diez seems to think that strongly-typed language can only deal with generic declarations by using something that allows circumventing the type system. In other words, you want Python to be strongly-typed, but sometimes you want to allow a reference to be to any object whatsoever. In which case you can't possibly do any sensible type-checking on it, so this new Python+ or whatever you want to call it will suffer from the same shortcomings that C++ and java do, which is to say type checking can't possibly do anything useful when the acceptable type of a reference is specified as ANY. And you are wrong. The problem with the C void* construct (I'm not that familiar with java) is that all type information is lost. When you use such a parameter in a function you have no idea what you are working with. But that doesn't need to be if you have a typesystem with an ANY type. Such a type declaration would mean that object of any type could be used here. However that doesn't imply that the type information of the actual objects used, has to be lost. That type information may still be available and usefull for further type checking. That you and Diez can only think about C, C++ or java constructs when I mention an ANY type, is your limitation. It doesn't need to be the limitation of a specific type system. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: Question
Hi, this email address does not exist. Please go to the site and use the correct form to send your message. No one has seen this message. Thanks Matchfinder -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
On Fri, 07 Oct 2005 06:01:00 -0400, Roy Smith wrote: There's more to it than just that. Python's type checking is not just not done at compile time, it's done as late in run time as possible. One might call it just-in-time type checking. Well there you go then. Instead of pulling our hair out that Python has no type checking (that's a bug in the language design, woe woe woe!!!) we can just say that Python does JIT type checking, which not only is a feature, but also satisfies the Pointy Haired Bosses who demand buzzwords they can't understand. -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Roy Smith a écrit : There's more to it than just that. Python's type checking is not just not done at compile time, it's done as late in run time as possible. One might call it just-in-time type checking. It's more of a Nearly too late type checking I would say. Not that I complain but it would be great if there were also some automatic type checking to catch a few errors as soon as possible. -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python book
I had the opportunity to glance through the book in Borders yesterday. On the whole, I think it is well covered and is very readable. Perhaps I was looking for a specific aspect, and I find that threads did not get enough attention. Looking at the index pages, the topics on threads (about 4-5 pages) is mainly found in the context of GUI programming. maurice Dick Moores wrote: (Sorry, my previous post should not have had Tutor in the subject header.) Magnus Lie Hetland's new book, _Beginning Python: From Novice to Professional_ was published by Apress on Sept. 26 (in the U.S.). My copy arrived in the mail a couple of days ago. Very much worth a look, IMHO. But what do the experts here think? http://www.bestbookdeal.com/book/compare/159059519X Dick Moores [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: check html file size
Xah Lee wrote: « would anyone like to translate the following perl
script to Python or Scheme (scsh)?»
Here's the Python version.
# -*- coding: utf-8 -*-
# Python
# Wed Oct 5 15:50:31 PDT 2005
# given a dir, report all html file's size. (counting inline images)
# XahLee.org
import re, os.path, sys
inpath= '/Users/t/web/'
while inpath[-1] == '/': inpath = inpath[0:-1] # get rid of trailing
slash
if (not os.path.exists(inpath)):
print dir + inpath + doesn't exist!
sys.exit(1)
##
# subroutines
def getInlineImg(file_full_path):
'''getInlineImg($file_full_path) returns a array that is a list of
inline images. For example, it may return ['xx.jpg','../image.png']'''
FF = open(file_full_path,'rb')
txt_segs = re.split( r'src', unicode(FF.read(),'utf-8'))
txt_segs.pop(0)
FF.close()
linx=[]
for linkBlock in txt_segs:
matchResult = re.search(r'\s*=\s*\([^\]+)\', linkBlock)
if matchResult: linx.append( matchResult.group(1) )
return linx
def linkFullPath(dir,locallink):
'''linkFullPath(dir, locallink) returns a string that is the full
path to the local link. For example,
linkFullPath('/Users/t/public_html/a/b', '../image/t.png') returns
'Users/t/public_html/a/image/t.png'. The returned result will not
contain double slash or '../' string.'''
result = dir + '/' + locallink
result = re.sub(r'//+', r'/', result)
while re.search(r'/[^\/]+\/\.\.', result): result =
re.sub(r'/[^\/]+\/\.\.', '', result)
return result
def listInlineImg(htmlfile):
'''listInlineImg($html_file_full_path) returns a array where each
element is a full path to inline images in the html.'''
dir=os.path.dirname(htmlfile)
imgPaths = getInlineImg(htmlfile)
result = []
for aPath in imgPaths:
result.append(linkFullPath( dir, aPath))
return result
##
# main
fileSizeList=[]
def checkLink(dummy, dirPath, fileList):
for fileName in fileList:
if '.html' == os.path.splitext(fileName)[1] and
os.path.isfile(dirPath+'/'+fileName):
totalSize = os.path.getsize(dirPath+'/'+fileName)
imagePathList = listInlineImg(dirPath+'/'+fileName)
for imgPath in imagePathList: totalSize +=
os.path.getsize(imgPath)
fileSizeList.append([totalSize, dirPath+'/'+fileName])
os.path.walk(inpath, checkLink, 'dummy')
fileSizeList.sort(key=lambda x:x[0],reverse=True)
for it in fileSizeList: print it
print done reporting.
-
This Python version is a direct translation of the Perl version. They
match pretty much line by line.
for both the Python version and the Perl version, see:
http://xahlee.org/perl-python/check_html_size.html
Would any lisper provides a Scheme version? i don't think i'll do a
Scheme version anytime soon. Please, Schemers, show us some fanfare.
Xah
[EMAIL PROTECTED]
∑ http://xahlee.org/
--
http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Christophe wrote: It's more of a Nearly too late type checking I would say. Not that I complain but it would be great if there were also some automatic type checking to catch a few errors as soon as possible. use assert as the soonest possible point. implementing type gates is trivial, if you think you need them. /F -- http://mail.python.org/mailman/listinfo/python-list
recursive function
Hello, In a recursive function like the following : def foo( j ) : j += 1 while j n : j = foo( j ) return j in found that the recursivity is limited (1000 iterations). Then, I have two questions : - why this mecanism has been implemented ? - it is possible to increase or remove (and how) the number of iterations ? Regards, Mathieu -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Op 2005-10-07, Diez B. Roggisch schreef [EMAIL PROTECTED]: Why do you call this a JAVA Object or C void*? Why don't you call it a PYTHON object. It is this kind of reaction that IMO tells most opponents can't think outside the typesystems they have already seen and project the problems with those type systems on what would happen with python should it acquire a type system. Well, because maybe I wanted you to give you an example of languages that are statically typed and have such an any construct But since I have no such type system in mind, such an example is useless. - that, by the way, is not a piece of inguine imagination of yours, but has been thought of before, e.g. CORBA (and called there any, too)? It makes no sense putting python into that context - as it is _not_ statically typed. Which you should know, after discussing this very subject way too long. The fact that something else uses the same name, for something doesn't mean it has to be implemented the same way. Would my suggestion be classified as a statically typed world? See above. Your answer tells more about you then about my suggestion. Your answer tells us something too: Just because you don't know anything about typechecking does not mean that you are in the position to make assumptions on how things could work if the people who know stuff wouldn't be so stupid. That's like saying cars can't fly because the stupid engineers lack my sense of imagination. Then argue against my ideas, and not your makings of it. If I just use 'ANY' and you fill that in with C void* like implementation and argue against that, then you are arguing against your own ghosts, but not against what I have in mind. It may very well turn out that my idea is useless, but I will only accept that when someone comes with arguments against my actual idea, and not with arguements against their projection of it. Just blathering about the possibility of some super-duper-typechecker and countering criticism or being told about problems in that domain by making bold statements that this sure could work - provide us with an implementation. You have not counterd my idea with criticism. You have decorated my idea with how you think it would be implemented (C void*) and argued against that. I don't need to give an implementation to notice, that you jumped to a particular implementation and basicly just countered that implementation, not the idea in general. Or maybe - just maybe - you could sit back and think about the fact that lots of people who are way cleverer than you and me have been working on this subject, and so far haven't found a way. Which doesn't necessarily mean that there is no way - but certainly its hard, theory-laden work and won't emerge in a NG discussion by some snide remarks of either you or anybody else. As far as I'm concerned that was just meant as a matter of fact remark, with no snide intentions. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: When someone from Britain speaks, Americans hear a British accent...
On Fri, 07 Oct 2005 09:01:21 +0100, Steve Holden wrote: and yes, I split that infinitive just to annoy any pedants who may be reading *Real* pedants will know that English is not Latin, does not follow the grammatical rules of Latin, and that just because split infinitives are impossible -- not forbidden, impossible -- in Latin is no reason to forbid them in English. The linguist Steven Pinker calls the sort of people who claim split infinitives are bad English language mavens, and he doesn't mean it as a compliment. See, for example, chapter 12 in his book The Language Instinct. [snip] Some village in Texas is missing their idiot. Several people defended this, saying that a village could use the plural possessive their. Several people being the idiots missed by the villages? :-) I personally found it odd (and essentially non-grammatical) not because either the singular or plural forms should be mandated but because this one manages to mix them up. So Some village in Texas are missing their idiot would be better (though it sounds like the kind of thing only the idiot alluded to would say), Absolutely. Some villages would work, but not village singular. while my preferred choice would be Some village in Texas is missing its idiot. Yes, that's the puppy. I think where the people are getting confused is that it is (arguably) acceptable to use their in place of his or her, as in: Should the purchaser lose their warranty card... Some of the more conservative grammarians argue against that construction, many accept it in informal speech or writing but not formal, and a few (like myself!) argue that it is time to get with the 21st century and just accept it even in formal language. If it was good enough for Willie Shakespeare, it is good enough for me. -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Fredrik Lundh a écrit : Christophe wrote: It's more of a Nearly too late type checking I would say. Not that I complain but it would be great if there were also some automatic type checking to catch a few errors as soon as possible. use assert as the soonest possible point. implementing type gates is trivial, if you think you need them. Still, it would be great if there were also some automatic type checking in place. Using assert is hardly automatic and non intrusive. I mean, why not ? Why does the compiler let me do that when you know perfectly that that code is incorrect : def f(): return a + 5 Of course the system can't be perfect but it doesn't need to be. It doesn't need to constrain us in any way but if it can detect some errors early, then it is worth it. -- http://mail.python.org/mailman/listinfo/python-list
Re: py2exe 0.6.3 released
Nice job~Thank you.On 10/7/05, Jimmy Retzlaff [EMAIL PROTECTED] wrote: py2exe 0.6.3 released=py2exe is a Python distutils extension which converts Python scriptsinto executable Windows programs, able to run without requiring aPython installation. Console and Windows (GUI) applications, Windows NT services, exe and dll COM servers are supported.Changes in 0.6.3:* First release assembled by py2exe's new maintainer, JimmyRetzlaff. Code changes in this release are from Thomas Heller and Gordon Scott.* The dll-excludes option is now available on the command line.It was only possible to specify that in the options argument tothe setup function before.The dll-excludes option can now be used to filter out dlls like msvcr71.dll or even w9xpopen.exe.* Fix from Gordon Scott: py2exe crashed copying extension modulesin packages.Changes in 0.6.2:* Several important bugfixes:- bundled extensions in packages did not work correctly, this made the wxPython single-file sample fail with newer wxPythonversions.- occasionally dlls/pyds were loaded twice, with very strangeeffects.- the source distribution was not complete. - it is now possible to build a debug version of py2exe.Changes in 0.6.1:* py2exe can now bundle binary extensions and dlls into thelibrary-archive or the executable itself.This allows to finally build real single-file executables.The bundled dlls and pyds are loaded at runtime by some specialcode that emulates the Windows LoadLibrary function - they arenever unpacked to the file system. This part of the code is distributed under the MPL 1.1, so thislicense is now pulled in by py2exe.* By default py2exe now includes the codecs module and theencodings package. * Several other fixes.Homepage:http://www.py2exe.orgDownload from the usual location: http://sourceforge.net/project/showfiles.php?group_id=15583Enjoy,Jimmy--http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: recursive function
mg wrote: Hello, In a recursive function like the following : def foo( j ) : j += 1 while j n : j = foo( j ) return j in found that the recursivity is limited (1000 iterations). Then, I have two questions : - why this mecanism has been implemented ? - it is possible to increase or remove (and how) the number of iterations ? Regards, Mathieu Try the following for answers to both questions: import sys print sys.setrecursionlimit.__doc__ I guess 1000 is the default value. -- http://mail.python.org/mailman/listinfo/python-list
Re: When someone from Britain speaks, Americans hear a British accent...
[Steve] and yes, I split that infinitive just to annoy any pedants who may be reading [Steven] *Real* pedants will know that English is not Latin, does not follow the grammatical rules of Latin, and that just because split infinitives are impossible -- not forbidden, impossible -- in Latin is no reason to forbid them in English. Your previous post to this thread was chock-full of split nominatives: The Hollywood voice, the specific regional accent, the English-speaking world, the original French. And you call yourself a grammarian. -- Richie Hindle [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: recursive function
Is there no way to implement your idea in a classical loop? Usually the syntax is cleaner, and there is no limit (except the limit of the range function in certain cases). For example what would be wrong with. def foo(j): while j n: j+=1 return j I don't know much about the internals of python, but to me it seems like if you're going to be doing this on the level of 1000s of iterations, there might be some overhead to using recursion (i.e. function calls) that a loop wouldn't have (but that's just a guess). Hello, In a recursive function like the following : def foo( j ) : j += 1 while j n : j = foo( j ) return j in found that the recursivity is limited (1000 iterations). Then, I have two questions : - why this mecanism has been implemented ? - it is possible to increase or remove (and how) the number of iterations ? Regards, Mathieu == Posted via Newsgroups.com - Usenet Access to over 100,000 Newsgroups == Get Anonymous, Uncensored, Access to West and East Coast Server Farms! == Highest Retention and Completion Rates! HTTP://WWW.NEWSGROUPS.COM == -- http://mail.python.org/mailman/listinfo/python-list
Re: recursive function
def foo(j): while j n: j+=1 return j of course I mean: def foo(j): while j n: j+=1 return j sorry == Posted via Newsgroups.com - Usenet Access to over 100,000 Newsgroups == Get Anonymous, Uncensored, Access to West and East Coast Server Farms! == Highest Retention and Completion Rates! HTTP://WWW.NEWSGROUPS.COM == -- http://mail.python.org/mailman/listinfo/python-list
Re: divide
Do the divisions have to be themselves rectangles? xB_C___x x_Ax would be a representation of the problem? However, though, I think that what you mean with your Points being smaller and things, is that the points are centered in the middle of their peice of the rectangle, whichs makes the problem really easy. If that is the case, notice that: width of Rectangle A = 2 * the_x_coordinate_ofA Subsequent widths can be found by subtracting the left side of the rectangle from the equation above. This is modified as follows width of Rectangle X = 2 * the_x_coordinate_ofX - width_so_far The height of your rectangles will all be the same (if i read the question right), so translating this to python is simple. On Oct 6, 2005, at 10:33 PM, Shi Mu wrote: I have three points in a rectangle and i wonder how to use PYTHON to divide the rectangle into three parts with each point located in the different part. For instance, Point A goes to Part I, Point B goes to Part II and Point C goes to Part III. And the distance between any point within Part I and Point A is smaller than to Point B and Point C. And the similar rule applies to Part II and Part III. Thanks for any idea. -- http://mail.python.org/mailman/listinfo/python-list --- Andrew Gwozdziewycz [EMAIL PROTECTED] http://ihadagreatview.org http://plasticandroid.org -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Fredrik Lundh [EMAIL PROTECTED] writes: use assert as the soonest possible point. implementing type gates is trivial, if you think you need them. What this is about (to me at least) is the edit-debug cycle. Let's say I write some Python code, using assert to validate datatypes. Maybe I've made 4 errors. I then write a test function and run it. Boom, the first assert fails. I fix the first error, run again. Boom, the next assert fails. Fix the next error, run again, boom, fix, etc. Four edit-debug cycles. With static typing, I run the compiler, get 4 error messages, fix all 4, and can get on with the next phase of testing with three fewer edit cycles. That's a definite benefit of languages like Java. It's not imaginary. Unit tests on Python code don't make it go away. I have less Java experience than Python experience by now, but I still find that Java programs take me fewer iterations to get working than Python programs. The trouble is that Java has a thousand deficiencies that outweigh that particular benefit, so overall I like Python a lot better anyway. Now some of the Python-is-perfect crowd seems to suffer from a Blub paradox (http://c2.com/cgi/wiki?BlubParadox). They see annoying, static typed languages like C and Java, and they see pleasant, dynamically typed languages like Python, and conclude that static types = annoying, when in fact they can be orthogonal. So, can there be a language that's both statically typed, and pleasant? I haven't used one yet, but lately I've been reading about Haskell and want to give it a try. I keep finding statements like: To me, Haskell is what Python should have evolved to. As a long-time Python programmer, I have been very, very pleased with Haskell and am currently working on porting my code to it (and write new code in Haskell at every opportunity). (http://supybot.com/Members/jemfinch/haskell-sucks/document_view) or: Using Haskell to develop OpenAFP.hs led to programs that eat constant 2MB memory, scale linearly, and are generally 2OOM faster than my Perl library. Oh, and the code size is 1/10. (http://www.perl.com/pub/a/2005/03/03/pugs_interview.html - Autrijus also raves about how great the book Types and Programming Languages supposedly is--I'm trying to borrow a copy. Yeah, this is a Perl comparison, but I think of Perl as being roughly equivalent to Python except a lot uglier). or: Haskell is the least-broken programming language available today. C, C++, Perl, Python, Java, and all the other languages you've heard of are all much more broken, so debating their merits is pointless. :-) Unfortunately Real Life involves dealing with brokenness. (http://www106.pair.com/rhp/books.html) or: In conducting the independent design review at Intermetrics, there was a significant sense of disbelief. We quote from [CHJ93]: It is significant that Mr. Domanski, Mr. Banowetz and Dr. Brosgol were all surprised and suspicious when we told them that Haskell prototype P1 (see appendix B) is a complete tested executable program. We provided them with a copy of P1 without explaining that it was a program, and based on preconceptions from their past experience, they had studied P1 under the assumption that it was a mixture of requirements specification and top level design. They were convinced it was incomplete because it did not address issues such as data structure design and execution order. (http://haskell.org/papers/NSWC/jfp.ps - this was from a bake-off for a military application where the Haskell solution had 85 lines of code to Ada's 767, C++'s 1105, and Relational Lisp's 274). Obviously I'm in the usual rose-colored-glasses phase of finding out about something new and interesting, but I can't help thinking these guys are onto something. Quite a few of the Haskell Cafe mailing list members seem to have come to Haskell from Python. (Haskell tutorial: http://www.isi.edu/~hdaume/htut/ - I've read most of this and it looks pretty cool--definitely a steeper learning curve than Python but the result looks a lot more powerful). -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python book
Maurice LING wrote: I had the opportunity to glance through the book in Borders yesterday. On the whole, I think it is well covered and is very readable. Perhaps I was looking for a specific aspect, and I find that threads did not get enough attention. Looking at the index pages, the topics on threads (about 4-5 pages) is mainly found in the context of GUI programming. maurice I don't have my hard copy of the book, but from memory and grepping over the soft copy, you appear to be correct. Remember, though, that this is a beginning book on Python and *I* would consider threading a more advanced topic. I think putting threading in the context of GUI programming is just about right for an intro book. - jmj -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Antoon Pardon wrote: Then argue against my ideas, and not your makings of it. If I just use 'ANY' and you fill that in with C void* like implementation and argue against that, then you are arguing against your own ghosts, but not against what I have in mind. Well, you didn't tell us what you had in mind. You just said let's introduce something like any. I showed you existing implementations of such a concept that have problems. You say thats not what _I_ have in mind, so your criticism doesn't apply. Guess what, I can't read your mind. But you did not tell me in what your idea is different from existing concepts. You have not counterd my idea with criticism. You have decorated my idea with how you think it would be implemented (C void*) and argued against that. I don't need to give an implementation to notice, that you jumped to a particular implementation and basicly just countered that implementation, not the idea in general. Again - where is your idea layed out in (more) detail, so that one can discuss them? That was all that I'm asking - which of course you carefully avoided... As far as I'm concerned that was just meant as a matter of fact remark, with no snide intentions. Where exactly come the facts? All I see is some vague there should be something better, by introducing ANY. But no details how typechecking then would work. I showed you that existing type systems can't properly cope with ANY so far and allow for much errors. Just saying but mine won't is a little bit thin, don't you think?l Diez -- http://mail.python.org/mailman/listinfo/python-list
Re: Python recipes: list mixin, improved timeit, etc
On Thu, 06 Oct 2005 21:03:33 -0700, barnesc wrote: I added some recipes to the Python Cookbook: - listmixin Use ListMixin to create custom list classes from a small subset of list methods: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/440656 That looks great. Now, if only I understood mixins: what are they, and what they are for, and in particular, how they differ from mere subclassing. I've spent some time searching for a good definition on the web, but the main problem I've found is that most discussions on mixins assume you already know what they are. Those that don't are talking about Ruby or Lisp or some other language other than Python. I don't speak those languages, so their code examples don't make a lot of sense to me. Anyhoo, I've struggled on, but obviously I Just Don't Get It because using mixins looks like subclassing to me. Can anyone help me understand what's going on? Thanks, -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
Python interpreter bug
Hello, I came accross what i think is a serious bug in the python interpreter. Membership testing seems not to work for list of objects when these objects have a user-defined __cmp__ method. It is present in Python 2.3 and 2.4. I don't know about other versions. The following code illustrates the bug: from random import choice class OBJ: def __init__(self,identifier): self.id=identifier self.allocated=0 def __cmp__(self,other): return cmp(other.allocated,self.allocated) mylist=[OBJ(i) for i in range(20)] excluded=[obj for obj in mylist if obj.idchoice(range(20))] for obj in mylist: if obj in excluded: assert obj.id in [objt.id for objt in excluded] continue Running the above snippet will trigger the assert. The culprit seems to be the __cmp__ method which sorts on a key with constant value. Best regards Alain -- http://mail.python.org/mailman/listinfo/python-list
Re: Python recipes: list mixin, improved timeit, etc
Well, suppose you have a class MyObject and you want to add to it some methods to make its instances into a database. You could put these methods into another class called Storable (the mixin class). Then you can mix MyObject with Storable and get what you want, a class StorableObject inheriting both from Storable and MyObject. Of course you can reuse Storable to make storable even other classes, for instance you could define a StorableOtherObject inheriting from OtherObject and Storable. Once in a time, I thought mixins where a good idea; now I don't think so since they are too easily abused (see Zope 2) and as a consequence you get spaghetti-inheritance, where you have objects with methods inherited from everywhere. So be very careful if you want to use mixins; often you can go without them. Just my 2 Euro cents, Michele Simionato -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
It is not about falling back on generic declarartion, it is about how such object will be treated. Diez seems to think that strongly-typed language can only deal with generic declarations by using something that allows circumventing the type system. No, I don't - now it's you who makes assumptions about what I think. ML and other FPs show that genericity can be done without circumvening. Templates and generics in C++ partially do so. In other words, you want Python to be strongly-typed, but sometimes you want to allow a reference to be to any object whatsoever. In which case you can't possibly do any sensible type-checking on it, so this new Python+ or whatever you want to call it will suffer from the same shortcomings that C++ and java do, which is to say type checking can't possibly do anything useful when the acceptable type of a reference is specified as ANY. And you are wrong. The problem with the C void* construct (I'm not that familiar with java) is that all type information is lost. When you use such a parameter in a function you have no idea what you are working with. You don't know JAVA - I do. And nobody said that it lost that type-information. It doesn't. Still, errors occur - namely ClassCastEcxeptions. That indicates that going back and forth via ANY doesn't necessarily lose any type information, but the capability of today's type-systems to keep that information across such a transition. This won't work: Object foo = A(); B bar = (B) foo; And please, pretty please don't argue with the simplicity of that example - think of a bazillion statements between these two, possibly done with run-time-instantiated classes that weren't known at compile-time. But that doesn't need to be if you have a typesystem with an ANY type. Such a type declaration would mean that object of any type could be used here. However that doesn't imply that the type information of the actual objects used, has to be lost. That type information may still be available and usefull for further type checking. JAVA has that. That you and Diez can only think about C, C++ or java constructs when I mention an ANY type, is your limitation. It doesn't need to be the limitation of a specific type system. Again: where are the specifics of this system? In your head? Tell us the gory detail, please. Diez -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Paul Rubin http://[EMAIL PROTECTED] wrote: What this is about (to me at least) is the edit-debug cycle. Let's say I write some Python code, using assert to validate datatypes. Maybe I've made 4 errors. I then write a test function and run it. Boom, the first assert fails. I fix the first error, run again. Boom, the next assert fails. Fix the next error, run again, boom, fix, etc. Four edit-debug cycles. With static typing, I run the compiler, get 4 error messages, fix all 4, and can get on with the next phase of testing with three fewer edit cycles. That's certainly the plan, but my experience is that it's not the whole story, for a few reasons. 1) I can often run 4 Python edit-debug cycles in the time it takes me to run a single C++ cycle, especially if there's a whole pile of build system gunk layered on top of the raw compile step. 2) When I get a bunch of compile errors, I know that many of them are just cascaded from a single problem. Thus, I tend to fix the first one and only take a quick look at all the others. If it's obvious what the problem is, I'll fix it, but as often as not, I'll just recompile and see what pops out the next time. 3) Many times, I'll spend more time making the compiler happy than the protection it affords me is worth. C++ is such a complex language, it's really hard to write a compiler which follows every detail of the spec, and the details are what kills you. We had a case the other day where a const_cast of a reference returned by a function worked just fine on Solaris, but failed on HPUX. We ended up with three guys digging through reference manuals trying to figure out how const_cast and references are supposed to interact. We ended up deciding what we were doing was legal, but we still had to devise a work-around so it compiled on all platforms. It's actually a little more complex than that, because we don't even write raw const_cast's, we use a CONST_CAST macro to work around older compilers that don't support modern casting, so we burned a little more time double-checking that our macro expansion wasn't at fault. We could have done a lot of Python edit-debug cycles in the time it took to sort that one out. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python recipes: list mixin, improved timeit, etc
Steven D'Aprano [EMAIL PROTECTED] writes: That looks great. Now, if only I understood mixins: what are they, and what they are for, and in particular, how they differ from mere subclassing. I'm not sure what you mean by mere subclassing so maybe there is no difference. Mixins are sort of a design pattern, not any whiz-tech thing. The terminology comes from Flavors which was one of the early multiple inheritance OOP systems. Flavors terminology was inspired by ice cream: you could go to Tosci's and get plain ice cream, or ice cream with your choice of various mix-ins like raisins, MM's, heath bar pieces, etc., which you could combine orthogonally. In Flavors and in Python, mix-ins are superclasses that you inherit to turn on a feature. The classic example is a Window class, with mixins for scroll bars, title bars, pulldown menu, etc. So if you want a window with a scroll bar, you'd say class Window_with_scroll_bar(Window, Scrollbar): pass and you'd get a class that understands the operations of both windows and scroll bars. Flavors had automatic method combination that you have to spell out manually in Python, making the scheme a little bit less useful. But see SocketServer for a clever example of mixins to implement concurrency in a TCP listener. The basic server class is TCPServer and you inherit from ThreadingMixin to make a threading server or ForkingMixin to make a forking server. I guess what makes something a mix-in is that you normally don't inherit from it directly. You inherit from some other class and the mix-in is an add-on superclass that supplies some extra functionality. -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Now some of the Python-is-perfect crowd seems to suffer from a Blub paradox (http://c2.com/cgi/wiki?BlubParadox). They see annoying, static typed languages like C and Java, and they see pleasant, dynamically typed languages like Python, and conclude that static types = annoying, when in fact they can be orthogonal. So, can there be a language that's both statically typed, and pleasant? I haven't used one yet, but lately I've been reading about Haskell and want to give it a try. Nobody says that there can't be possibly better languages like python overall, or for specific tasks. However, this discussion is about introducing type-checking to python. And as someone who has done his fair share of FP programming let me assure you that - all declarations are fully type annotated. The inference only comes into play on _expressions_. The result in python would be that you'd have to write def foo(x:int):int : return 10 but then could use x = foo() which made the inference possible. But it _doesn't figure out that foo returns an int because there is one returned, and misses the :int in the declaration! Genericity is reached through solving somewhat more complicated type equations - but these still require declarations: def bar(l:list[whatever]):whatever : return head(l) x = bar([10]) can be resolved as [] will me a list-constructor that gets passed an int literal - wich in turn means that whatever as type-variable is bound to int, and thus x is an int, as that is the return type of bar. - FPs share their own set of problems - try writing a server. The have inherent troubles with event-driven programs. Then you need monads, and that makes things a little bit more ugly... Still, FP is cool. But python too. And just attaching some type-inference to python won't work. Diez -- http://mail.python.org/mailman/listinfo/python-list
Re: Python recipes: list mixin, improved timeit, etc
Michele Simionato [EMAIL PROTECTED] writes: Once in a time, I thought mixins where a good idea; now I don't think so since they are too easily abused (see Zope 2) and as a consequence you get spaghetti-inheritance, where you have objects with methods inherited from everywhere. So be very careful if you want to use mixins; often you can go without them. Yeah, I wonder though how much of that is a result of Python's cavalier approach to multiple inheritance. Does that happen much in CLOS? In Java because of multiple interfaces? I've studied Flavors a little and mix-ins were used in some extensive ways, but maybe programs using them required extra care. The Python tutorial does caution against indiscriminate use of multiple inheritance. I tried coding something without it, wished that I'd used it and did so in the next version, but still am not sure if I gained anything or not. -- http://mail.python.org/mailman/listinfo/python-list
CSV like file format featured recently in Daily Python URL?
I'm trying to track down the name of a file format and python module, that was featured in the Daily Python URL some time in the last month or two. The format was ASCII with a multiline header defining types for the comma seperated column data below. It may have had the capability to store multiple tables in one file. There was news on the homepage that an alternate 'no data here' syntax was also supported. An example file had vaguely this structure: columnname as datatype columnname as datatype columnname as datatype columnname as datatype data,data,data,data data,other data,data,data data,data,,data Can anyone remember this file format/python module? With thanks Alex -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Diez B. Roggisch [EMAIL PROTECTED] writes: - FPs share their own set of problems - try writing a server. The have inherent troubles with event-driven programs. Erlang? Still, FP is cool. But python too. And just attaching some type-inference to python won't work. Yeah, I've figured declarations in Python would be more like Common Lisp's, i.e. optional, enforced at compile time only when the compiler can easily figure it out, and at runtime otherwise. -- http://mail.python.org/mailman/listinfo/python-list
Re: Continuous system simulation in Python
[Robert Kern] [...] an ODE integrator would probably want to adaptively select its timesteps as opposed to laying out a uniform discretization upfront. Eons ago, I gave myself such a little beast (but really found in an Appendix of a book on simulation), which I use since then whenever I need it, not so often in these days. If you are curious, see: http://fp-etc.progiciels-bpi.ca/rke.html yet I'm sure there is just plenty of such things, all around. The above is in C, not in Python. I vaguely remember having once rewritten the thing in Python, then discarded the result as not fast enough for the need I then had. If I really needed to use it nowadays, I'll probably try to quickly link it through Pyrex. Or just look around a bit for some already made, and maybe better solution. :-) It is easy and convenient, when writing a mixed discrete and continuous simulation system, to tie the advancement control of the various active ODE solvers within the main loop of the discrete event scheduler. -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list
Re: Python recipes: list mixin, improved timeit, etc
On Fri, 07 Oct 2005 05:11:00 -0700, Michele Simionato wrote: Well, suppose you have a class MyObject and you want to add to it some methods to make its instances into a database. You could put these methods into another class called Storable (the mixin class). Then you can mix MyObject with Storable and get what you want, a class StorableObject inheriting both from Storable and MyObject. Of course you can reuse Storable to make storable even other classes, for instance you could define a StorableOtherObject inheriting from OtherObject and Storable. So mixins are just a sub-class [pun intended] of sub-classing? I've just found this: [quote] A mixin class is a parent class that is inherited from - but not as a means of specialization. Typically, the mixin will export services to a child class, but no semantics will be implied about the child being a kind of the parent. [end quote] from http://c2.com/cgi/wiki?MixIn Is that all they are? It is amazing how you can take the simplest concept, and by using appropriate terminology, make it as confusing and opaque as you want... *wink* -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Paul Rubin wrote: Diez B. Roggisch [EMAIL PROTECTED] writes: - FPs share their own set of problems - try writing a server. The have inherent troubles with event-driven programs. Erlang? Guess what, worked with that, too :) And let me assure you - it does have pretty much runtime type error issues. It's interpreted. I'm not sure what the compiler/parser gets at loading a source file. And the Mnesia distributed database lets you easily query the wrong values... It's interesting, and it's concurrent programming paradigms are great. But it's far from being perfect, and needs thourough testing before deploying new code. Still, FP is cool. But python too. And just attaching some type-inference to python won't work. Yeah, I've figured declarations in Python would be more like Common Lisp's, i.e. optional, enforced at compile time only when the compiler can easily figure it out, and at runtime otherwise. Easy cases are easy... The thing is: I'm all for typechecking as long as it doesn't burden me. In FP it doesn't, as the expressional power is way better. But in JAVA, it does. And just doing wishful-thinking about that Python should do better that won't help... :) Diez -- http://mail.python.org/mailman/listinfo/python-list
Re: When someone from Britain speaks, Americans hear a British accent...
Richie Hindle wrote: [Steve] and yes, I split that infinitive just to annoy any pedants who may be reading [Steven] *Real* pedants will know that English is not Latin, does not follow the grammatical rules of Latin, and that just because split infinitives are impossible -- not forbidden, impossible -- in Latin is no reason to forbid them in English. Your previous post to this thread was chock-full of split nominatives: The Hollywood voice, the specific regional accent, the English-speaking world, the original French. And you call yourself a grammarian. I am presuming this post was meant to be a joke? No smileys, though, so you force us to make up our own minds. Or is the green tomato also unacceptable? regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC www.holdenweb.com PyCon TX 2006 www.python.org/pycon/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Can Python replace TCL/Expect
On Thu, 06 Oct 2005 17:08:03 GMT, Cameron Laird [EMAIL PROTECTED] wrote: In article [EMAIL PROTECTED], Jorgen Grahn [EMAIL PROTECTED] wrote: . . . It depends. I do not feel /that/ advanced, but I've been bitten by pexpect's limitations several times in several places. ... which puts me in a weird position ;-) I /loathe/ the Tcl language, but I have to admit that its expect functionality is far superior to Python's. . . . On to more constructive matters: what are you doing about Pexpect's limitations? Have the maintainers responded to you when you write? Are you tempted to compose enhancements for yourself? There is hobby hacking, and there is work. I've encountered pexpect during work, and haven't had the time and energy to look into it. I hereby apologize to the pexpect developers. Not for whining, but for not helping out. /Jorgen -- // Jorgen Grahn jgrahn@ Ph'nglui mglw'nafh Cthulhu \X/algonet.se R'lyeh wgah'nagl fhtagn! -- http://mail.python.org/mailman/listinfo/python-list
Re: Python recipes: list mixin, improved timeit, etc
Steven D'Aprano [EMAIL PROTECTED] writes: On Thu, 06 Oct 2005 21:03:33 -0700, barnesc wrote: I added some recipes to the Python Cookbook: - listmixin Use ListMixin to create custom list classes from a small subset of list methods: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/440656 That looks great. Now, if only I understood mixins: what are they, and what they are for, and in particular, how they differ from mere subclassing. One way to look at it is that mixins are a special case of subclassing. They aren't different, just specific. Mixins are abstract. Using Paul's example, you'd never declare a ScrollBar object, only subclasses that also inherit from some form of Window. Mixins are about behavior, not type. If you have real mixins, then an object of a class that inherits from a mixin is not an instance of the mixin class. Mixins are one way to deal with the lack of multiple inheritance. But even languages with multiple inheritance find the idea useful. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python recipes: list mixin, improved timeit, etc
Paul Rubin wrote: Yeah, I wonder though how much of that is a result of Python's cavalier approach to multiple inheritance. Does that happen much in CLOS? In Java because of multiple interfaces? I've studied Flavors a little and mix-ins were used in some extensive ways, but maybe programs using them required extra care. I don't think Python approach to multiple inheritance is cavalier (you may want to clarify that statement). In CLOS multiple inheritance is less of a problem since (multi)methods are defined outside classes. One could argue that using classes also as a scope-control mechanism (i.e. doing the job of modules) is an abuse. The Python tutorial does caution against indiscriminate use of multiple inheritance. I tried coding something without it, wished that I'd used it and did so in the next version, but still am not sure if I gained anything or not. Nowadays I tend to use delegation via __getattr__ instead of multiple inheritance. Michele Simionato -- http://mail.python.org/mailman/listinfo/python-list
Re: Can't extend function type
Diez B. Roggisch wrote: Paul Rubin wrote: Oh well. I had wanted to be able to define two functions f and g, and have f*g be the composition of f and g. func_type = type(lambda: None) class composable_function(func_type): ... def __mult__(f,g): ... def c(*args, **kw): ... return f(g(*args, **kw)) ... return c ... Traceback (most recent call last): File stdin, line 1, in ? TypeError: Error when calling the metaclass bases type 'function' is not an acceptable base type Seems like a wart to me. So the only way to achieve this with current semantics is to make f anf g objects with a call methods. In that very moment, you're done - as extending from object is no problem :) class ComposeableFunction(object): def __call__(self, *args, **kwargs): return self.second(self.first(*args, **kwargs)) Note, with a little bit of massaging, you can turn ComposableFunction into a decorator, for more natural function definition: (Untested, I'm not on a system with Py2.4 at the moment): class Composable(object): def __init__(self,f): self.callable = f def __call__(self,*args, **kwargs): return self.callable(*args, **kwargs) def __mul__(self,other): return Composable(lambda (*a, **kwa): self.callable(other(*a, **kwa))) Usage: @Composable def f(x): return x**2 @Composable def g(x): return x+1 # And we shouldn't even need a @Composable on the last in the sequence def h(x): return x/2.0 f(1) 1 (f*g)(1) 4 (f*g*h)(2) 4 This might not combine neatly with methods, however; the bound/unbound method magic is still mostly voodoo to me. -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Christophe wrote: Fredrik Lundh a écrit : Christophe wrote: It's more of a Nearly too late type checking I would say. Not that I complain but it would be great if there were also some automatic type checking to catch a few errors as soon as possible. use assert as the soonest possible point. implementing type gates is trivial, if you think you need them. Still, it would be great if there were also some automatic type checking in place. Using assert is hardly automatic and non intrusive. I mean, why not ? Why does the compiler let me do that when you know perfectly that that code is incorrect : def f(): return a + 5 Of course the system can't be perfect but it doesn't need to be. It doesn't need to constrain us in any way but if it can detect some errors early, then it is worth it. While this is a perfectly acceptable feature request, we should remember that Python is developed and maintained by a volunteer team. Do we *really* want them spending their time adding features like this? regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC www.holdenweb.com PyCon TX 2006 www.python.org/pycon/ -- http://mail.python.org/mailman/listinfo/python-list
BayPIGgies: October 13, 7:30pm (IronPort)
The next meeting of BayPIGgies will be Thurs, October 13 at 7:30pm at IronPort. Tim Thompson will describe and demonstrate the interaction between Burning Man and Python using two applications, Radio Free Quasar and Ergo. BayPIGgies meetings alternate between IronPort (San Bruno, California) and Google (Mountain View, California). For more information and directions, see http://www.baypiggies.net/ Before the meeting, we sometimes meet at 6pm for dinner. Discussion of dinner plans is handled on the BayPIGgies mailing list. Advance notice: We've got some options on the plate for November 10 but haven't settled anything yet. Please send e-mail to [EMAIL PROTECTED] if you want to suggest an agenda (or volunteer to give a presentation). The meeting agenda for December 8 has been set. -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ The way to build large Python applications is to componentize and loosely-couple the hell out of everything. -- http://mail.python.org/mailman/listinfo/python-list
Re: Simple prototype text editor in python
Thanks for everyones advice. I finally went for a very basic BSD style template that I found somewhere. Its really short and easy to understand, at least to me! -- http://mail.python.org/mailman/listinfo/python-list
Re: Book Python and Tkinter Programming
striker wrote: Does anyone who has this book willing to sell it. Please e-mail me the condition and any other details if you are interested. Thanks, Kevin half.com has a couple of people selling it. One for $35.24 and another for $129.97. -- http://mail.python.org/mailman/listinfo/python-list
How to run python scripts with IDLE
Hi all, My problem is # I have to run a script which takes a command line parameter which is unicode text # I cant use Windows console as it doesnt support /display unicode # I dont seems to find a way to pass command line arguments to scripts in IDLE. Please suggest me what I can do. Thanks in Advance Ravi -- http://mail.python.org/mailman/listinfo/python-list
Re: Continuous system simulation in Python
François Pinard wrote: [Robert Kern] [...] an ODE integrator would probably want to adaptively select its timesteps as opposed to laying out a uniform discretization upfront. Eons ago, I gave myself such a little beast (but really found in an Appendix of a book on simulation), which I use since then whenever I need it, not so often in these days. If you are curious, see: http://fp-etc.progiciels-bpi.ca/rke.html yet I'm sure there is just plenty of such things, all around. The above is in C, not in Python. I vaguely remember having once rewritten the thing in Python, then discarded the result as not fast enough for the need I then had. If I really needed to use it nowadays, I'll probably try to quickly link it through Pyrex. Or just look around a bit for some already made, and maybe better solution. :-) scipy has wrapped LSODA and VODE from ODEPACK. There are a few more integrators in ODEPACK which could easily be wrapped with f2py should someone feel the urge. We'd probably wrap yours, too, if it weren't GPLed. ;-) -- Robert Kern [EMAIL PROTECTED] In the fields of hell where the grass grows high Are the graves of dreams allowed to die. -- Richard Harter -- http://mail.python.org/mailman/listinfo/python-list
Python recipes: list mixin, improved timeit, etc
So mixins are just a sub-class [pun intended] of sub-classing? I've just found this: [quote] A mixin class is a parent class that is inherited from - but not as a means of specialization. Typically, the mixin will export services to a child class, but no semantics will be implied about the child being a kind of the parent. [end quote] from http://c2.com/cgi/wiki?MixIn Is that all they are? It is amazing how you can take the simplest concept, and by using appropriate terminology, make it as confusing and opaque as you want... *wink* A mixin is an atomic unit in an object-oriented language that adds functionality to another class. - http://www.macromedia.com/support/documentation/en/flex/1/mixin/ mixin2.html#118542 The only experience I've had with mixins is in Python, where UserDict has a class DictMixin that defines the full dictionary interface from a minimal subset of dictionary methods. The Python docs don't define mixin. I just assumed this was a case where a programmer needed a name more descriptive than foo, so he called it mixin, and that stuck. :) - Connelly Barnes -- http://mail.python.org/mailman/listinfo/python-list
Re: Python interpreter bug
Why would it be a bug? You've made it so that every instance of OBJ is equal to every other instance of OBJ. The behaviour is as expected. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python interpreter bug
[EMAIL PROTECTED] wrote: Hello, I came accross what i think is a serious bug in the python interpreter. Membership testing seems not to work for list of objects when these objects have a user-defined __cmp__ method. It is present in Python 2.3 and 2.4. I don't know about other versions. The following code illustrates the bug: from random import choice class OBJ: def __init__(self,identifier): self.id=identifier self.allocated=0 def __cmp__(self,other): return cmp(other.allocated,self.allocated) mylist=[OBJ(i) for i in range(20)] excluded=[obj for obj in mylist if obj.idchoice(range(20))] for obj in mylist: if obj in excluded: assert obj.id in [objt.id for objt in excluded] continue I presume you just put the continue in there for fun? for obj in mylist: ... print obj in excluded ... True True True True True True True True True True True True True True True True True True True True OBJ(0) == OBJ(1) True Running the above snippet will trigger the assert. The culprit seems to be the __cmp__ method which sorts on a key with constant value. Well indeed. As far as I can see your objects will all test equal. Did you mean the __cmp__ method to return cmp(other.id, self.id)? regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC www.holdenweb.com PyCon TX 2006 www.python.org/pycon/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Merging sorted lists/iterators/generators into one stream of values...
Lasse Vågsæther Karlsen [EMAIL PROTECTED] wrote: Ok, that one looks more sleak than what I came up with. For the most efficient and elegant solution, check out Raymond Hettinger's reply to: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/141934 George -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Op 2005-10-07, Diez B. Roggisch schreef [EMAIL PROTECTED]: Antoon Pardon wrote: Then argue against my ideas, and not your makings of it. If I just use 'ANY' and you fill that in with C void* like implementation and argue against that, then you are arguing against your own ghosts, but not against what I have in mind. Well, you didn't tell us what you had in mind. Indeed I hadn't. It wasn't needed for the question I posed then. You just said let's introduce something like any. I showed you existing implementations of such a concept that have problems. But as far as I can see that is a problem of the implementation not necessarily of the concept. You say thats not what _I_ have in mind, so your criticism doesn't apply. Guess what, I can't read your mind. But you did not tell me in what your idea is different from existing concepts. Indeed you can't read my mind, but what pops up in your mind shows your preconceptions. You could have just answered the question as it was posed, instead of filling in the details yourself, maybe remarking that you didn't see how it would work with current type systems you know off. You have not counterd my idea with criticism. You have decorated my idea with how you think it would be implemented (C void*) and argued against that. I don't need to give an implementation to notice, that you jumped to a particular implementation and basicly just countered that implementation, not the idea in general. Again - where is your idea layed out in (more) detail, so that one can discuss them? That was all that I'm asking - which of course you carefully avoided... Sure I'm reluctant to give details. I consider this a hostile environment, for this kind of proposals. I'm sure people will be able to come up with all kind of problems my idea won't solve and will see this as a reason to think the idea is useless. Since I have no intention to As far as I'm concerned that was just meant as a matter of fact remark, with no snide intentions. Where exactly come the facts? About how you filled in the details yourself when all I mentioned was a type system with an ANY type. All I see is some vague there should be something better, by introducing ANY. But no details how typechecking then would work. I showed you that existing type systems can't properly cope with ANY so far and allow for much errors. Just saying but mine won't is a little bit thin, don't you think?l The main idea is that type information would be available at two places. 1) The names, which carry the declared type. 2) The objects which carry the type/class they belong too. When an object is bound to a name, a check is made that the type of the object is compatible with the declared type of the name. A name with type ANY, would be just like any python variable or instance now. Python could implement this by instead of storing its variables in dictionaries as (name, value) tuples, by storing them as (name, declaration, value) tuples and making the necesarry checks at (re)bind time. Variables that are not declared would get the ANY declaration so that current scripts would just remain working as they do now. But as the compiler got more sophisticated some of these checks might be doable at compile time instead of at run time. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: Python interpreter bug
There is definitely a bug. Maybe the follownig snippet is more clear: class OBJ: def __init__(self,identifier): self.id=identifier self.allocated=0 #def __cmp__(self,other): # return cmp(other.allocated,self.allocated) mylist=[OBJ(i) for i in range(10)] excluded=[obj for obj in mylist if obj.id in [2,4,6,8]] exclusion_list_by_id=[2,4,6,8] print 'exclusion list by id=',exclusion_list_by_id for obj in mylist: print 'current obj=',obj.id, if obj in excluded: print ' --- THIS OBJECT IS EXCLUDED' assert obj.id in exclusion_list_by_id continue print If you uncomment the two lines, the assert will be erroneously triggered. Alain -- http://mail.python.org/mailman/listinfo/python-list
Re: Merging sorted lists/iterators/generators into one stream of values...
Thanks, that looks like Mike's solution except that it uses the built-in heapq module. While this one contains less code than Mike's solution it seems to lack the ability to control the comparison operation, which means it won't work in my case. I need to both be able to sort on an arbitrary field name (could be done using a list where I place the field first), and also to be able to sort in a different order than smallest-first. Perhaps by adjusting the data that is returned through each source would do that. I'll look into it. -- http://mail.python.org/mailman/listinfo/python-list
Re: no variable or argument declarations are necessary.
Diez B. Roggisch [EMAIL PROTECTED] writes: Erlang? Guess what, worked with that, too :) And let me assure you - it does have pretty much runtime type error issues. It's interpreted. Yes, it makes no attempt at being statically typed. It's like Python that way, AFAIK. Easy cases are easy... The thing is: I'm all for typechecking as long as it doesn't burden me. In FP it doesn't, as the expressional power is way better. But in JAVA, it does. And just doing wishful-thinking about that Python should do better that won't help... :) How about Lisp? It seems to do some good there, without getting in the way. -- http://mail.python.org/mailman/listinfo/python-list
Python 2nd favorite language in Linux Journal poll
Linux Journal annually polls its readers on questions such as their favorite programming language. In the 2005 poll, Python is 2nd, its highest ranking ever. Below are the results by year. I wish that rankings beyond the first 3 were available and that the number of votes were shown. Nerds like numbers, not journalist blather :). I found this data for earlier years by Googling linux journal readers choice awards. 2005 1. C++ 2. Python 3. PHP 2004 Favorite Programming Language 1. C 2. Perl 3. C++ Ah, favorite programming language-time for a flame war. A bit of a shake-up this year: after being knocked out of first place last year, C reclaims it this year and C++ drops to third. The P language in the top three is Perl, while PHP slips to fourth place, closely followed by Python. The voting was close this year, too; only 59 votes separated C from C++. 2003 Favorite Programming Language 1. C++ 2. C 3. PHP Quick, everyone to your keyboard: the flame war begins in 5, 4, 3, 2In a reversal of last year's winner and runner-up, C++ moved into first place in 2003 by a mere 23 votes. Perl, meanwhile, got kicked out of the top three for the first time in the history of our awards. Continuing the C theme, C# is the favorite write-in vote. 2002 Favorite Programming Language 1. C 2. C++ 3. Perl C++ kicked Perl out of the second-favorite position this year, and only 17 votes kept C++ out of the top spot. In its first year on the ``official'' list, Kylix/Object Pascal came in fourth. Following that was a close vote spread between PHP, Java and Python, in that order. One quite reasonable voter wrote in that he uses ``whichever is best for the project''. And to the voter who felt bad about preferring bash shell scripting, don't worry, you're not alone. 2001 Favorite Programming Language 1. C 2. Perl 3. C++ Here's another category where we took your advice from last year and split C/C++ into separate categories because, hey, they're not the same. Java and PHP finish out the top five, with Python just missing out by 15 votes. Kylix/Object Pascal had a strong write-in showing, over 200 votes. 2000 1. C/C++ 2. Perl 3. Java ``Plain C (without the ++).'' The perennial C/C++ wins 40% of your votes this year. To everyone who took the time to remind us that C and C++ are not the same language, we hear you loud and clear. Second and third place go to Perl and Java, while Python continues to expand its fan base by claiming 8%. 1999 1. C/C++ 2. Perl 3. Java ``Something wants to make me vote for Logo... but I'll spare you. :)'' The old UNIX standard--the closest thing we have to a cross-platform assembler--wins nearly half the vote at 49.4%. We'll have to split C and C++ next year; we received countless ``I hate C++'' comments, a sentiment shared by nearly everyone who voted. Perl had an excellent showing, with 20.6% of the vote, compared to the up-and-coming Python which scored 4%. At 9.5%, Java appears to have become rather popular, and a concerted effort from PHP enthusiasts managed to score it 4.6%. Emacs (meaning ELisp, probably) received a large number of write-ins. Doesn't anyone use assembly code anymore? 1998 1. Perl 2. Tcl/Tk -- http://mail.python.org/mailman/listinfo/python-list
Re: Python interpreter bug
[EMAIL PROTECTED] wrote: I came accross what i think is a serious bug in the python interpreter. Membership testing seems not to work for list of objects when these objects have a user-defined __cmp__ method. it does not work if they have *your* __cmp__ method, no. if you add a print statement to the method, you'll figure out why: def __cmp__(self,other): print CMP, other.allocated, self.allocated return cmp(other.allocated,self.allocated) /F -- http://mail.python.org/mailman/listinfo/python-list
Re: When someone from Britain speaks, Americans hear a British accent...
[Richie] Your previous post to this thread was chock-full of split nominatives: The Hollywood voice, the specific regional accent, the English-speaking world, the original French. And you call yourself a grammarian. [Steve] I am presuming this post was meant to be a joke? It was. No smileys, though, so you force us to make up our own minds. Yes. 8-) Or is the green tomato also unacceptable? It ought to be considered unacceptable by people who think that to correctly apply is unacceptable, which is the point that Stephen was making: *Real* pedants will know that English is not Latin, does not follow the grammatical rules of Latin, and that just because split infinitives are impossible -- not forbidden, impossible -- in Latin is no reason to forbid them in English. Split nominatives like the green tomato are also impossible in Latin, but no-one seems to object to their use in English. -- Richie Hindle [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Python interpreter bug
Sorry Fredrik but I don't understand. Just comment out the assert and you have different results depending on whether an unrelated sort function is defined. This seems weird to me ! -- http://mail.python.org/mailman/listinfo/python-list
Re: Can't extend function type
Diez B. Roggisch [EMAIL PROTECTED] writes: Well - function inheritance is not known so far in python - and in no other language I know. Yeah, I didn't really expect it to work, but it seems like a logical consequence of type/class unification. Basically you want __mult__ being part of f or g when python encounters something like this f * g But then how did you plan to declare f? Come to think of it, that's also a wart. I'd been thinking of using a decorator, as Christopher Subich suggested, @composable def f(x): ... but it's not how the decorator could actually work (other than through gross CPython-specific hacks). So the only way to achieve this with current semantics is to make f anf g objects with a call methods. In that very moment, you're done - as extending from object is no problem :) Yeah, I thought of that, but felt it wasn't in the proper spirit :) -- http://mail.python.org/mailman/listinfo/python-list
Re: [Info] PEP 308 accepted - new conditional expressions
Robin Becker wrote: As mentioned earlier only a dictator can make such decisions and of course as with many dictatorships the wrong decision is often made. There's no such thing as a benevolent dictatorship. Ever cared to check what committees can do to a language ;-) --eric -- http://mail.python.org/mailman/listinfo/python-list
