Re: [Python-Dev] Typo.pl scan of Python 2.5 source code
"Neal Norwitz" <[EMAIL PROTECTED]> writes: > I ignored these as I'm not certain all the platforms we run on accept > free(NULL). It's mandated by C99, and I don't *think* it changed from the previous version (I only have a bootleg copy of C99 :). Cheers, mwh -- TRSDOS: Friendly old lizard. Or, at least, content to sit there eating flies.-- Jim's pedigree of operating systems, asr ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Minipython
Milan Krcmar wrote: > Thank you people. I'm going to try to strip unneeded things and let you > know the result. > > Along with running Python on an embedded system, I am considering two > more things. Suppose the system to be a small Linux router, which, after > the kernel starts, merely configures lots of parameters of the kernel > and then runs some daemons for gathering statistics and allowing remote > control of the host. > > Python helps mainly in the startup phase of configuring kernel according > to a human-readable confgiuration files. This has been solved by shell > scripts. Python is not as suitable for running external processes and > process pipes as a shell, but I'd like to write a module (at least) > helping him in the sense of scsh (a "Scheme shell", > http://www.scsh.net). > > A more advanced solution is to replace system's init (/sbin/init) by > Python. It should even speed the startup up as it will not need to run > shell many times. To avoid running another processes, I want to "port > them" to Python. Processes for kernel configuration, like iproute2, > iptables etc. are often built above its own library, which can be used as > a start point. (Yes, it does matter, at startup, routers run such processes > hundreds times). > > Milan One alternative you might want to look into is the language "Lua" (www.lua.org), which is similar to Python in some respects (also has some similarities to Javascript), but specifically optimized for embedding in larger apps - meaning that it has a much smaller footprint, a much smaller standard library, less built-in data types and so on. (For example, dicts, lists, and objects are all merged into a single type called a 'table', which is just a generic indexable container.) Lua's C API consists of just a few dozen functions. It's not as powerful as Python of course, although it's surprisingly powerful for its size - it has closures, continuations, and all of the goodness you would expect from a modern language. Lua provides 'meta-mechanisms' for extending the language rather than implementing language features directly. So even though it's not a pure object-oriented language, it provides mechanisms for implementing classes and inheritance. And it's fast, since it has less baggage to carry around. It has a few warts - for example, I don't like the fact that referring to an undefined variable silently returns nil instead of returning an error, but I suppose in some environments that's a feature. A lot of game companies use Lua for embedded scripting languages in their games. (Console-based games in particular have strict memory requirements, since there's no virtual memory on consoles.) -- Talin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.5 bug? Changes in behavior of traceback module
Thanks! Mike Georg Brandl wrote: > Michael Glassford wrote: >> In Python 2.4, traceback.print_exc() and traceback.format_exc() silently >> do nothing if there is no active exception; in Python 2.5, they raise an >> exception. Not too difficult to handle, but unexpected (and a pain if >> you use it in a lot of places). I assume it was an unintentional change? > > This was certainly an unintentional change while restructuring some > internal traceback routines. > > It's now fixed in SVN. > > Georg > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] python-dev summary for 2006-08-01 to 2006-08-15
Sorry about the delay. Here's the summary for the first half of
August. As always, comments and corrections are greatly appreciated.
=
Summaries
=
Mixing str and unicode dict keys
Ralf Schmitt noted that in Python head, inserting str and unicode keys
to the same dictionary would sometimes raise UnicodeDecodeErrors::
>>> d = {}
>>> d[u'm\xe1s'] = 1
>>> d['m\xe1s'] = 1
Traceback (most recent call last):
...
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe1 in
position 1: ordinal not in range(128)
This error showed up as a result of Armin Rigo's `patch to stop dict
lookup from hiding exceptions`_, which meant that the
UnicodeDecodeError raised when a str object is compared to a non-ASCII
unicode object was no longer silenced. In the end, people agreed that
UnicodeDecodeError should not be raised for equality comparisons, and
in general, ``__eq__()`` methods should not raise exceptions. But
comparing str and unicode objects is often a programming error, so in
addition to just returning False, equality comparisons on str and
non-ASCII unicode now issues a warning with the UnicodeDecodeError
message.
.. _patch to stop dict lookup from hiding exceptions:
http://bugs.python.org/1497053
Contributing threads:
- `unicode hell/mixing str and unicode as dictionary keys
`__
- `Dicts are broken Was: unicode hell/mixing str and unicode
asdictionarykeys
`__
- `Dicts are broken ...
`__
- `Dict suppressing exceptions
`__
---
Rounding floats to ints
---
Bob Ippolito pointed out a long-standing bug in the struct module
where floats were automatically converted to ints. Michael Urman
showed a simple case that would provoke an exception if the bug were
fixed::
pack('>H', round(value * 32768))
The source of this bug is the expectation that ``round()`` returns an
int, when it actually returns a float. There was then some discussion
about splitting the round functionality into two functions:
``__builtin__.round()`` which would round floats to ints, and
``math.round()`` which would round floats to floats. There was also
some discussion about the optional argument to ``round()`` which
currently specifies the number of decimal places to round to -- a
number of folks felt that it was a mistake to round to *decimal*
places when a float can only truly reflect *binary* places.
In the end, there were no definite conclusions about the future of
``round()``, but it seemed like the discussion might be resumed on the
Python 3000 list.
Contributing threads:
- `struct module and coercing floats to integers
`__
- `Rounding float to int directly (Re: struct module and coercing
floats to integers)
`__
- `Rounding float to int directly (Re: struct module and coercing
floats to integers)
`__
- `Rounding float to int directly ...
`__
- `struct module and coercing floats to integers
`__
---
Assigning to function calls
---
Neal Becker proposed that code by ``X() += 2`` be allowed so that you
could call __iadd__ on objects immediately after creation. People
pointed out that allowing augmented *assignment* is misleading when no
assignment can occur, and it would be better just to call the method
directly, e.g. ``X().__iadd__(2)``.
Contributing threads:
- `SyntaxError: can't assign to function call
`__
- `Split augmented assignment into two operator sets? [Re:
SyntaxError: can't assign to function call]
`__
---
PEP 357: Integer clipping and __index__
---
After some further discussion on the `__index__ issue`_ of last
fortnight, Travis E. Oliphant proposed `a patch for __index__`_ that
introduced three new C API functions:
* PyIndex_Check(obj) -- checks for nb_index
* PyObject* PyNumber_Index(obj) -- calls nb_index if possible or
raises a TypeError
* Py_ssize_t PyNumber_AsSsize_t(obj, err) -- converts the object to a
Py_ssize_t, raising err on overflow
After a few minor edits, this patch was checked in.
.. __index__ issue:
http://www.python.org/dev/summary/2006-07-16_2006-07-31/#pep-357-integer-clipping-and-index
[Python-Dev] 2.4.4c1 October 11, 2.4.4 final October 18
The plan for 2.4.4 is to have a release candidate on October 11th, and a final release on October 18th. This is very likely to be the last ever 2.4 release, after which 2.4.4 joins 2.3.5 and earlier in the old folks home, where it can live out it's remaining life with dignity and respect. If you know of any backports that should go in, please make sure you get them done before the 11th. Anthony ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.4.4c1 October 11, 2.4.4 final October 18
Anthony Baxter wrote: > The plan for 2.4.4 is to have a release candidate on October 11th, and a final > release on October 18th. This is very likely to be the last ever 2.4 release, > after which 2.4.4 joins 2.3.5 and earlier in the old folks home "finally leaves school" is a more correct description, I think. my 2.3 and 2.4 installations are in a pretty good shape, after all... ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
