Re: [Python-Dev] address manipulation in the standard lib
On Mon, Jan 5, 2009 at 9:10 AM, Duncan McGreggor wrote: > Last Fall, Guido opened a ticket to include Google's ipaddr.py in the > standard lib: > http://bugs.python.org/issue3959 > > There has been some recent discussion on that ticket, enough so that > it might benefit everyone if it was moved on to the dev list. I do > recommend reading that ticket, though -- lots of good perspectives are > represented. > > The two libraries that are being discussed the most for possible > inclusion are the following: > * http://code.google.com/p/ipaddr-py/wiki/IPAddrExmples > * http://code.google.com/p/netaddr/wiki/NetAddrExamples > > The most immediately obvious differences between the two are: > * ipaddr supports subnet/supernet/net exclusions > * netaddr supports EUI/MAC address manipulations > * the netaddr API differentiates between an IP and a CIDR block > * netaddr supports wildcard notation > * netaddr supports binary representations of addresses > * ipaddr is one module whereas netaddr consists of several (as well > as IANA data for such things as vendor lookups on MAC addresses) > * ipaddr benchmarks as faster than netaddr > * netaddr is currently PEP-8 compliant > > That's a quick proto-assessment based on looking at examples and unit > tests and didn't include a thorough evaluation of the code itself. Thanks for the summary! I've been on vacation and unable to follow the details. Note that I have no vested interest in Google's module except knowing it has many happy users (I have never used it myself). > Martin provided some very nice guidelines in a comment on the ticket: > > "I think Guido's original message summarizes [what we need]: a module > that fills a gap for address manipulations... In addition, it should > have all the organisational qualities (happy user base, determined > maintainers, copyright forms, documentation, tests). As to what > precisely its API should be - that is for the experts (i.e. you) to > determine. I personally think performance is important, in addition to > a well-designed, useful API. Conformance to PEP 8 is also desirable." > > I'm planning to chat with both David Moss (netaddr) and Peter Moody > (ipaddr) on the mail lists about API details, and I encourage others > to do this as well. As for this list, it's probably important to > define the limits of the desired feature set for an ip address > manipulation library: > * do we want to limit it to IP (i.e. no EUI/MAC support)? I don't want to exclude EUI/MAC support, but it seems quit a separate (and much more specialized) application area, so it's probably best to keep it separate (even if it may make sense to use a common (abstract or concrete) base class or just have similar APIs). > * do we want a single module or is a package acceptable? I don't care either way. > * what features would folks consider essential or highly desirable > (details on this will be discussed on the project mail lists) > * other thoughts? How about a merger? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org 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.org OS
Leif Walsh writes: > True, most of the upgrade problems deal with packages that aren't in > the server install. This should be an easy one, but now I'd ask, why > not use Debian instead? You mean, "why not stick with Debian instead?" The reason is that Debian stable lags the real world dramatically. It's an extremely stable platform (in all meanings of "stable"), but quite restrictive. Ubuntu's LTS versions are much more up-to-date. Debian "sid" is out, obviously, and Debian "testing" has the problem that it is a fairly fast-moving target. Not so much as "sid", but if I were the sysadmin, I would not be happy with installing "testing" as of some date, knowing that many components would not correspond to that tag within hours, at most days. It's a hard question IMO. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] #ifdef __cplusplus?
On 2009-01-03 04:15, Adam Olsen wrote:
> On Fri, Jan 2, 2009 at 9:05 AM, M.-A. Lemburg wrote:
>> On 2009-01-02 08:26, Adam Olsen wrote:
>>> Python's malloc wrappers are pretty messy. Of your examples, only
>>> unicode->str isn't obvious what the result is, as the rest are local
>>> to that function. Even that is obvious when you glance at the line
>>> above, where the size is calculated using sizeof(Py_UNICODE).
>>>
>>> If you're concerned about correctness then you'd do better eliminating
>>> the redundant malloc wrappers and giving them names that directly
>>> match what they can be used for.
>> ??? Please read the comments in pymem.h and objimpl.h.
>
> I count 7 versions of malloc. Despite the names, none of them are
> specific to PyObjects. It's pretty much impossible to know what
> different ones do without a great deal of experience.
Is it ? I suggest you read up on the Python memory management and the
comments in the header files. The APIs are pretty straight forward...
http://docs.python.org/c-api/allocation.html
http://docs.python.org/c-api/memory.html
> Only very specialized uses need to allocate PyObjects directly anyway.
> Normally PyObject_{New,NewVar,GC_New,GC_NewVar} are better.
Better for what ? The APIs you referenced are only used to
allocate Python objects.
The malloc() wrappers provide a sane interface not only for
allocating Python objects, but also for arbitrary memory
chunks, e.g. ones referenced by Python objects.
>>> If the size calculation bothers you you could include the semantics of
>>> the PyMem_New() API, which includes the cast you want. I've no
>>> opposition to including casts in a single place like that (and it
>>> would catch errors even with C compilation).
>> You should always use PyMem_NEW() (capital letters), if you ever
>> intend to benefit from the memory allocation debug facilities
>> in the Python memory allocation interfaces.
>
> I don't see why such debugging should require a full recompile, rather
> than having a hook inside the PyMem_Malloc (or even providing a
> different PyMem_Malloc).
Of course it does: you don't want the debug overhead in a
production build.
>> The difference between using the _NEW() macros and the _MALLOC()
>> macros is that the first apply overflow checking for you. However,
>> the added overhead only makes sense if these overflow haven't
>> already been applied elsewhere.
>
> They provide assertions. There's no overflow checking in release builds.
See above. Assertions are not meant to be checked in a production
build. You use debug builds for debugging such low-level things.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Jan 05 2009)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/
::: Try our new mxODBC.Connect Python Database Interface for free !
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
http://www.egenix.com/company/contact/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] address manipulation in the standard lib
On Mon, Jan 5, 2009 at 11:44 AM, Guido van Rossum wrote: > On Mon, Jan 5, 2009 at 9:10 AM, Duncan McGreggor > wrote: >> Last Fall, Guido opened a ticket to include Google's ipaddr.py in the >> standard lib: >> http://bugs.python.org/issue3959 >> >> There has been some recent discussion on that ticket, enough so that >> it might benefit everyone if it was moved on to the dev list. I do >> recommend reading that ticket, though -- lots of good perspectives are >> represented. >> >> The two libraries that are being discussed the most for possible >> inclusion are the following: >> * http://code.google.com/p/ipaddr-py/wiki/IPAddrExmples >> * http://code.google.com/p/netaddr/wiki/NetAddrExamples >> >> The most immediately obvious differences between the two are: >> * ipaddr supports subnet/supernet/net exclusions >> * netaddr supports EUI/MAC address manipulations >> * the netaddr API differentiates between an IP and a CIDR block >> * netaddr supports wildcard notation >> * netaddr supports binary representations of addresses >> * ipaddr is one module whereas netaddr consists of several (as well >> as IANA data for such things as vendor lookups on MAC addresses) >> * ipaddr benchmarks as faster than netaddr >> * netaddr is currently PEP-8 compliant >> >> That's a quick proto-assessment based on looking at examples and unit >> tests and didn't include a thorough evaluation of the code itself. > > Thanks for the summary! I've been on vacation and unable to follow the > details. Note that I have no vested interest in Google's module except > knowing it has many happy users (I have never used it myself). > >> Martin provided some very nice guidelines in a comment on the ticket: >> >> "I think Guido's original message summarizes [what we need]: a module >> that fills a gap for address manipulations... In addition, it should >> have all the organisational qualities (happy user base, determined >> maintainers, copyright forms, documentation, tests). As to what >> precisely its API should be - that is for the experts (i.e. you) to >> determine. I personally think performance is important, in addition to >> a well-designed, useful API. Conformance to PEP 8 is also desirable." >> >> I'm planning to chat with both David Moss (netaddr) and Peter Moody >> (ipaddr) on the mail lists about API details, and I encourage others >> to do this as well. As for this list, it's probably important to >> define the limits of the desired feature set for an ip address >> manipulation library: > >> * do we want to limit it to IP (i.e. no EUI/MAC support)? > > I don't want to exclude EUI/MAC support, but it seems quit a separate > (and much more specialized) application area, so it's probably best to > keep it separate (even if it may make sense to use a common (abstract > or concrete) base class or just have similar APIs). > >> * do we want a single module or is a package acceptable? > > I don't care either way. > >> * what features would folks consider essential or highly desirable >> (details on this will be discussed on the project mail lists) >> * other thoughts? > > How about a merger? I think that's a brilliant idea. David and Peter, logistics aside, what do you think of (or how to you feel about) this suggestion? Or, if not a complete merger, unifying everything that is desired in the standard library. The code not included (e.g. EUI/MAC address stuff, vendor lookups, etc.) could continue its existence as a project, using the stdlib as a basis... d ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Roundup version numbers
Hi! To craete this issue compilation [0] I use roundup through its web interface. For example, to know which version names corresponds to each number, I consulted them through: http://bugs.python.org/version But since two weeks ago, this list was trimmed down. I think that it was to not be able to submit bugs for older Python versions, which is great, but there're some bugs assigned to older versions (for example, [1]). So, question: Should I use another way to query the version number-name relationship (to see them all)? Or those issues that point to older Python versions should be updated? Thank you!! [0] http://www.taniquetil.com.ar/cgi-bin/pytickets.py [1] http://bugs.python.org/iss...@search_text=&title=&@columns=title&id=&@columns=id&creation=&creator=&activity=&@columns=activity&@sort=activity&actor=&nosy=&type=&components=&versions=4&dependencies=&assignee=&keywords=&priority=&@group=priority&status=1&@columns=status&resolution=&@pagesize=50&@startwith=0&@queryname=&@old-queryname=&@action=search -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] address manipulation in the standard lib
Last Fall, Guido opened a ticket to include Google's ipaddr.py in the standard lib: http://bugs.python.org/issue3959 There has been some recent discussion on that ticket, enough so that it might benefit everyone if it was moved on to the dev list. I do recommend reading that ticket, though -- lots of good perspectives are represented. The two libraries that are being discussed the most for possible inclusion are the following: * http://code.google.com/p/ipaddr-py/wiki/IPAddrExmples * http://code.google.com/p/netaddr/wiki/NetAddrExamples The most immediately obvious differences between the two are: * ipaddr supports subnet/supernet/net exclusions * netaddr supports EUI/MAC address manipulations * the netaddr API differentiates between an IP and a CIDR block * netaddr supports wildcard notation * netaddr supports binary representations of addresses * ipaddr is one module whereas netaddr consists of several (as well as IANA data for such things as vendor lookups on MAC addresses) * ipaddr benchmarks as faster than netaddr * netaddr is currently PEP-8 compliant That's a quick proto-assessment based on looking at examples and unit tests and didn't include a thorough evaluation of the code itself. Martin provided some very nice guidelines in a comment on the ticket: "I think Guido's original message summarizes [what we need]: a module that fills a gap for address manipulations... In addition, it should have all the organisational qualities (happy user base, determined maintainers, copyright forms, documentation, tests). As to what precisely its API should be - that is for the experts (i.e. you) to determine. I personally think performance is important, in addition to a well-designed, useful API. Conformance to PEP 8 is also desirable." I'm planning to chat with both David Moss (netaddr) and Peter Moody (ipaddr) on the mail lists about API details, and I encourage others to do this as well. As for this list, it's probably important to define the limits of the desired feature set for an ip address manipulation library: * do we want to limit it to IP (i.e. no EUI/MAC support)? * do we want a single module or is a package acceptable? * what features would folks consider essential or highly desirable (details on this will be discussed on the project mail lists) * other thoughts? d ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Why is there still a PRINT_EXPR opcode in Python 3?
On Mon, Jan 5, 2009 at 00:53, Benjamin Peterson wrote: > On Sun, Jan 4, 2009 at 5:36 PM, wrote: >> >>>> Since print is now a builtin function why is there still a PRINT_EXPR >>>> opcode? >> >>Benjamin> I believe it's used in the interactive interpreter to display >>Benjamin> the repr of an expression. >> >> Wouldn't it make more sense for the interactive interpreter to call >> >>print(repr(expr)) > > I'm not sure about the reasoning for keeping PRINT_EXPR alive. When I > look at the code of PyRun_InteractiveOne, it seems it should be > possible to kill it off. How would you display multiple lines, like: >>> for x in range(3): ...x, x * x ... (0, 0) (1, 1) (2, 4) >>> if 1: ... "some line" ... "another line" ... 'some line' 'another line' OTOH this seems an obscure feature. "for" and "if" are statements after all. -- Amaury Forgeot d'Arc ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] issue 3582
http://bugs.python.org/issue3582 I submitted a patch last august, but have had no comments. Any thoughts? Here is a suggested update to thread_nt.c. It has two significant changes: 1) it uses the new and safer _beginthreadex API to start a thread 2) it implements native TLS functions on NT, which are certain to be as fast as possible. Kristján ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Why is there still a PRINT_EXPR opcode in Python 3?
On Mon, Jan 5, 2009 at 4:25 AM, Amaury Forgeot d'Arc wrote: > On Mon, Jan 5, 2009 at 00:53, Benjamin Peterson wrote: >> On Sun, Jan 4, 2009 at 5:36 PM, wrote: >>> >>>>> Since print is now a builtin function why is there still a PRINT_EXPR >>>>> opcode? >>> >>>Benjamin> I believe it's used in the interactive interpreter to display >>>Benjamin> the repr of an expression. >>> >>> Wouldn't it make more sense for the interactive interpreter to call >>> >>>print(repr(expr)) >> >> I'm not sure about the reasoning for keeping PRINT_EXPR alive. When I >> look at the code of PyRun_InteractiveOne, it seems it should be >> possible to kill it off. > > How would you display multiple lines, like: > for x in range(3): > ...x, x * x > ... > (0, 0) > (1, 1) > (2, 4) if 1: > ... "some line" > ... "another line" > ... > 'some line' > 'another line' > > OTOH this seems an obscure feature. "for" and "if" are statements after all. That feature may be obscure but should not be killed. It'd be a bit tricky to remove the PRINT_EXPR call since it doesn't invoke the print() function -- it invokes something more basic that goes through sys.displayhook. I don't care about the opcode, but the semantics should remain unchanged. Keeping the opcode is probably easiest. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Small question about BufferedRandom spec
Hello, Amaury (mainly) and I are rewriting the IO stack in C, and there is a small thing in PEP 3116 about the BufferedRandom object that I'd like to clarify: « Q: Do we want to mandate in the specification that switching between reading and writing on a read-write object implies a .flush()? Or is that an implementation convenience that users should not rely on? » Is it ok if I assume that the answer is "it is an implementation convenience that users should not rely on"? The reason is that I'm overhauling BufferedRandom objects to use a single shared buffer, so as to optimize interleaved reads and writes. Thanks Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r68182 - in python/trunk: Lib/decimal.py Misc/NEWS
Our of curiousity, why are these constants for internal use only? Is there concern that people might start using "is", or is it just to keep the (beyond the spec) API small, or ...? -jJ On Fri, Jan 2, 2009 at 6:07 PM, mark. dickinson wrote: > Author: mark.dickinson > Date: Sat Jan 3 00:07:08 2009 > New Revision: 68182 > > Log: > Issue #4812: add missing underscore prefix to some internal-use-only > constants in the decimal module. (Dec_0 becomes _Dec_0, etc.) > > > > Modified: > python/trunk/Lib/decimal.py > python/trunk/Misc/NEWS > > Modified: python/trunk/Lib/decimal.py > == > --- python/trunk/Lib/decimal.py (original) > +++ python/trunk/Lib/decimal.py Sat Jan 3 00:07:08 2009 > @@ -216,7 +216,7 @@ > if args: > ans = _dec_from_triple(args[0]._sign, args[0]._int, 'n', True) > return ans._fix_nan(context) > -return NaN > +return _NaN > > class ConversionSyntax(InvalidOperation): > """Trying to convert badly formed string. > @@ -226,7 +226,7 @@ > syntax. The result is [0,qNaN]. > """ > def handle(self, context, *args): > -return NaN > +return _NaN > > class DivisionByZero(DecimalException, ZeroDivisionError): > """Division by 0. > @@ -242,7 +242,7 @@ > """ > > def handle(self, context, sign, *args): > -return Infsign[sign] > +return _Infsign[sign] > > class DivisionImpossible(InvalidOperation): > """Cannot perform the division adequately. > @@ -253,7 +253,7 @@ > """ > > def handle(self, context, *args): > -return NaN > +return _NaN > > class DivisionUndefined(InvalidOperation, ZeroDivisionError): > """Undefined result of division. > @@ -264,7 +264,7 @@ > """ > > def handle(self, context, *args): > -return NaN > +return _NaN > > class Inexact(DecimalException): > """Had to round, losing information. > @@ -290,7 +290,7 @@ > """ > > def handle(self, context, *args): > -return NaN > +return _NaN > > class Rounded(DecimalException): > """Number got rounded (not necessarily changed during rounding). > @@ -340,15 +340,15 @@ > def handle(self, context, sign, *args): > if context.rounding in (ROUND_HALF_UP, ROUND_HALF_EVEN, > ROUND_HALF_DOWN, ROUND_UP): > -return Infsign[sign] > +return _Infsign[sign] > if sign == 0: > if context.rounding == ROUND_CEILING: > -return Infsign[sign] > +return _Infsign[sign] > return _dec_from_triple(sign, '9'*context.prec, > context.Emax-context.prec+1) > if sign == 1: > if context.rounding == ROUND_FLOOR: > -return Infsign[sign] > +return _Infsign[sign] > return _dec_from_triple(sign, '9'*context.prec, > context.Emax-context.prec+1) > > @@ -1171,12 +1171,12 @@ > if self._isinfinity(): > if not other: > return context._raise_error(InvalidOperation, '(+-)INF * > 0') > -return Infsign[resultsign] > +return _Infsign[resultsign] > > if other._isinfinity(): > if not self: > return context._raise_error(InvalidOperation, '0 * > (+-)INF') > -return Infsign[resultsign] > +return _Infsign[resultsign] > > resultexp = self._exp + other._exp > > @@ -1226,7 +1226,7 @@ > return context._raise_error(InvalidOperation, > '(+-)INF/(+-)INF') > > if self._isinfinity(): > -return Infsign[sign] > +return _Infsign[sign] > > if other._isinfinity(): > context._raise_error(Clamped, 'Division by infinity') > @@ -1329,7 +1329,7 @@ > ans = context._raise_error(InvalidOperation, 'divmod(INF, > INF)') > return ans, ans > else: > -return (Infsign[sign], > +return (_Infsign[sign], > context._raise_error(InvalidOperation, 'INF % x')) > > if not other: > @@ -1477,7 +1477,7 @@ > if other._isinfinity(): > return context._raise_error(InvalidOperation, 'INF // INF') > else: > -return Infsign[self._sign ^ other._sign] > +return _Infsign[self._sign ^ other._sign] > > if not other: > if self: > @@ -1732,12 +1732,12 @@ > if not other: > return context._raise_error(InvalidOperation, > 'INF * 0 in fma') > -product = Infsign[self._sign ^ other._sign] > +product = _Infsign[self._sign ^ other._sign] > elif other._exp == 'F':
Re: [Python-Dev] Roundup version numbers
> But since two weeks ago, this list was trimmed down. I think that it > was to not be able to submit bugs for older Python versions, which is > great, but there're some bugs assigned to older versions (for example, > [1]). All true. > Should I use another way to query the version number-name relationship > (to see them all)? Or those issues that point to older Python versions > should be updated? All existing associations between versions and issues stay as they are. I don't quite understand what the problem is. Yes, the versions were "retired" (in roundup speak), and yes, issues that were originally associated with the retired versions stay associated. So what is the problem with that? If you want to find out all versions, including retired ones, you need to iteratively go through the list, asking for, say http://bugs.python.org/version4 (there might also be an XML-RPC interface to do that). OTOH, if you had downloaded the list of versions once, you can trust that each id continues to mean what it meant on creation, so you might want to look only for updates (i.e. newer ids). If you are suggesting that all such issues should be retargeted at newer versions: certainly not: Many issues were for old versions, and have long been closed. For the open issues, such retargetting would have to go along with a check whether the issue still exists in the newer versions. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ParseTuple question
Funny, I was just looking at this code. Anyway, whenever I need Unicode stuff as an argument, I use this idiom: PyObject *uO; PyObject *uU; Py_UNICODE *u; If (!PyArg_ParseTuple(args, "O", &uO)) return 0; uU = PyUnicode_FromObject(uO); if (!uU) return 0; u = PyUnicode_AS_UNICODE(uU); There is no automatic conversion in PyArg_ParseTuple, because there is no temporary place to store the converted item. It does work the other way round (turning a Unicode object to a char*) because the Unicode object has a default conversion member slot to store it. It should be possible to augment the PyArg_ParseTuple to provide a slot for a temporary object, something like: PyArg_ParseTuple(args, "u", &uU, &u) K -Original Message- From: python-dev-bounces+kristjan=ccpgames@python.org [mailto:python-dev-bounces+kristjan=ccpgames@python.org] On Behalf Of Ulrich Eckhardt Sent: 2. janúar 2009 11:33 To: python-dev@python.org Subject: [Python-Dev] ParseTuple question Hi! I'm looking at NullImporter_init in import.c and especially at the call to PyArg_ParseTuple there. What I'm wondering is what that call will do when I call the function with a Unicode object. Will it convert the Unicode to a char string first, will it return the Unicode object in a certain (default) encoding, will it fail? I'm working on the MS Windows CE port, and I don't have stat() there. Also, I don't have GetFileAttributesA(char const*) there, so I need a wchar_t (UTF-16) string anyway. What would be the best way to get one? Thanks! Uli ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/kristjan%40ccpgames.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] address manipulation in the standard lib
>> How about a merger? > > I think that's a brilliant idea. David and Peter, logistics aside, > what do you think of (or how to you feel about) this suggestion? the devil, as they say, is in the details :). I'd be interested to know what form this merger would take. WRT v4/v6 manipulation, it seems that ipaddr and netaddr do very similar things, though with different strategies. I've never worked on integrating code into a project like this before, so i'm not sure what a merger like this would end up looking like. having said that, I am fine with this in principal. Cheers, /peter ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Small question about BufferedRandom spec
On Mon, Jan 5, 2009 at 12:01 PM, Antoine Pitrou wrote: > Amaury (mainly) and I are rewriting the IO stack in C, Very cool! > and there is a small > thing in PEP 3116 about the BufferedRandom object that I'd like to clarify: > > « Q: Do we want to mandate in the specification that switching between reading > and writing on a read-write object implies a .flush()? Or is that an > implementation convenience that users should not rely on? » > > Is it ok if I assume that the answer is "it is an implementation convenience > that users should not rely on"? The reason is that I'm overhauling > BufferedRandom objects to use a single shared buffer, so as to optimize > interleaved reads and writes. I think it's fine if the flush to the file is optional, as long as this is clearly documented. However, the semantics of interleaving reads and writes, with and without seek calls in between, should be well-defined and correct/useful, so that it behaves the same regardless of the buffer size. Ditto for the flush call currently implied by a seek -- if you can satisfy the seek by moving where you are in the buffer without flushing, that's fine IMO, but it should be well documented. It should also be documented that a flush still *may* occur, of course. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] #ifdef __cplusplus?
On 5/01/2009 11:13 PM, M.-A. Lemburg wrote: See above. Assertions are not meant to be checked in a production build. You use debug builds for debugging such low-level things. Although ironically, assertions have been disabled in debug builds on Windows - http://bugs.python.org/issue4804 Cheers, Mark. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Flushing email queue
If there's anything (be it a python-dev issue, or something for python-committers, or a bug) that needs my attention, please resend. In order to start getting work done today, I am archiving all python-related email from the last 2.5 weeks unread that doesn't have me explicitly in the To: or CC: header. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] another Python Bug Day?
Dear python-dev group, are their any plans to organize another Python Bug Day in the near future? It's been a while since the last one (last May). I might be misremembering, but I think at one time there was even talk of having one bug day every month. For people who are not core developers but would still like to contribute, the Bug Days are quite exciting events. It would be great if they could keep going. Malte ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Roundup version numbers
2009/1/5 "Martin v. Löwis" : > All existing associations between versions and issues stay as they are. > I don't quite understand what the problem is. Yes, the versions were > "retired" (in roundup speak), and yes, issues that were originally > associated with the retired versions stay associated. So what is the > problem with that? The problem is that I don't have a way to find out the relation number-name for the versions (see below). > (there might also be an XML-RPC interface to do that). OTOH, if you had > downloaded the list of versions once, you can trust that each id I didn't download the list versions once, so far I got it everytime from the server (it was cheap, because it's short, and I don't have the issue of the local copy becoming obsolete if something changed). How I donwloaded it everytime? I went to http://bugs.python.org/version and parsed the id and name for each line. But I can not do this anymore. > continues to mean what it meant on creation, so you might want to look > only for updates (i.e. newer ids). I guess I could do this, if there's no other way to have all the (id, name) pairs for all the existing version values. Thank you! -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] address manipulation in the standard lib
A merger sounds like a good way forward.
It shouldn't be as painful as it might sound initially and there should be
lots of room for some early big wins.
Contentious Issues
--
*** Separate IP and CIDR classes
The IP and CIDR object split in netaddr is going to require some further
discussion. They are mostly related to what operations to keep and which to
drop from each. More on this later on when I've had some time to think about
it a bit more.
*** Using the Stategy pattern
I'd like to see us use the GoF strategy pattern in a combined solution with
a single IP class for both v4 and v6, with separate strategy classes (like
netaddr), rather than two separate IPv4 and IPv6 classes returned by a
factory function (like ipaddr). Again this might require a bit of further
discussion.
Killer Features
---
Here's a list of (hopefully uncontroversial) features for a combined module
*** Maintain ipaddr speeds
Impressive stuff - I like it!
*** PEP-8 support
*** Drop MAC and EUI support
I'm happy to let the MAC (EUI-48) and EUI-64 support find a good home in a
separate module. Guido's sense of this being something separate is spot on
despite the apparent benefits of any code sharing. Where necessary, the
separate module can import whatever it needs from our combined module.
*** Pythonic behaving of IP objects
IP address objects behave like standard Python types (ints, lists, tuples,
etc) dependent on context.
This is mainly achieved via copious amounts of operator overloading.
For example, instead of :-
>>> IP('192.168.0.0/24').exclude_addrs('192.168.0.15/32')
['192.168.0.0/29', '192.168.0.8/30', '192.168.0.12/31', '192.168.0.14/32']
you could just implement __sub__ (IP object subtraction) :-
>>> IP('192.168.0.0/24', format=str) - IP('192.168.0.15/32')
['192.168.0.0/29', '192.168.0.8/30', '192.168.0.12/31', '192.168.0.14/32']
Achieving the same results but in a more Python friendly manner.
Here's a list of operators I've so far found decent meanings for in netaddr
:-
__int__, __long__, __str__, __repr__, __hash__
__eq__, __ne__, __lt__, __le__, __gt__, __ge__
__iter__, __getitem__, __setitem__, __len__, __contains__
__add__, __sub__, __isub__, __iadd__
*** Constants for address type identification
Identifying specific address types with a constant is essential. netaddr has
the module level constants AT_INET and AT_INET6 for IPv4 and IPv6
respectively. I'll be the first to agree that AT_* is a bit quirky. As we
are looking to something for the stdlib we should use something more, well,
standard such as AF_INET and AF_INET6 from the socket module.
Is AF_INET6 fairly widely available on most operating systems these days?
Not sure how socket constants have fared in Google's App Engine socket
module implementation for example. If not, we can always define some
specifically for the module itself.
*** Use the Python descriptor protocol to police IP objects attribute
assignments
This makes IP object properties read/writable rather than just read-only.
I discovered this on the Python mailing list a while back in the early days
of netaddr's development. They are excellent and open up a whole new world
of possibilities for keeping control of your objects internal state once you
allow users write access to your class properties.
*** Formatter attributes on IP objects to controls return value
representations
Sometimes you just want the string or hex representation of an address
instead of grokking IP objects the whole time. A useful trick when combined
with descriptor protocol above.
*** Use iterators
I notice ipaddr doesn't currently use the 'yield' statement anywhere which
is a real shame. netaddr uses iterators everywhere and also defines an
nrange() function built as an xrange() work-a-like but for network addresses
instead of integers values (very similar).
*** Add support for IPv4 address abbreviations
Based on 'old school' IP classful networking rules. Still useful and worth
having.
*** Use slices on IP objects!
There's nothing quite like list slices on a network object ;-) I've got some
horrendous issues trying to get this going with Python n-bit integers for
IPv6 so I'd love to see this working correctly.
*** Careful coding to avoid endianness bugs
I spent a decent chunk of development time early on doing endian tests on
all basic integer conversion operations. Any combined solution must be rock
solid and robust in this area. It's all too make naive assumption and get
this wrong. OK, so it's a pet hate of mine! I'm looking forward to Python
stdlib buildbot support in this area ;-)
*** Display of IP objects as human-readable binary strings
Sometimes it's just nice to see the bit patterns!
*** Python 'set' type operations for collections of IP objects
Intersection, union etc between network objects and groups of network
objects. More nice to have than essential but would be interesting to see
working. I've spent time thinking about it but haven'
Re: [Python-Dev] another Python Bug Day?
Hello, Malte Helmert informatik.uni-freiburg.de> writes: > > are their any plans to organize another Python Bug Day in the near > future? It's been a while since the last one (last May). I might be > misremembering, but I think at one time there was even talk of having > one bug day every month. We must first release 3.0.1 (there are a few release blockers remaining), but I also think we should do a Bug Day afterwards. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] another Python Bug Day?
On Mon, Jan 5, 2009 at 8:44 PM, Antoine Pitrou wrote: > > Hello, > > Malte Helmert informatik.uni-freiburg.de> writes: >> >> are their any plans to organize another Python Bug Day in the near >> future? It's been a while since the last one (last May). I might be >> misremembering, but I think at one time there was even talk of having >> one bug day every month. > > We must first release 3.0.1 (there are a few release blockers remaining), but > I > also think we should do a Bug Day afterwards. +1 It will be nice to deal with some of the bugs we had to put off during the RC phases of 2.6 and 3.0. -- Regards, Benjamin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Small question about BufferedRandom spec
Guido van Rossum wrote: « Q: Do we want to mandate in the specification that switching between reading and writing on a read-write object implies a .flush()? Or is that an implementation convenience that users should not rely on? » Is it ok if I assume that the answer is "it is an implementation convenience that users should not rely on"? The reason is that I'm overhauling BufferedRandom objects to use a single shared buffer, so as to optimize interleaved reads and writes. I think it's fine if the flush to the file is optional, as long as this is clearly documented. However, the semantics of interleaving reads and writes, with and without seek calls in between, should be well-defined and correct/useful, so that it behaves the same regardless of the buffer size. I don't know how much of the stdio will be wrapped or replaced, but, FWIW, the C89 Standard, as described by Plauger & Brodie, requires a position-setting operation between writes and reads: one of fflush, fseek, fsetpos, or rewind. Same for reads and writes unless the read set EOF. Ditto for the flush call currently implied by a seek -- if you can satisfy the seek by moving where you are in the buffer without flushing, that's fine IMO, but it should be well documented. It should also be documented that a flush still *may* occur, of course. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Small question about BufferedRandom spec
On Mon, Jan 5, 2009 at 8:13 PM, Terry Reedy wrote: > Guido van Rossum wrote: > >>> « Q: Do we want to mandate in the specification that switching between >>> reading >>> and writing on a read-write object implies a .flush()? Or is that an >>> implementation convenience that users should not rely on? » >>> >>> Is it ok if I assume that the answer is "it is an implementation >>> convenience >>> that users should not rely on"? The reason is that I'm overhauling >>> BufferedRandom objects to use a single shared buffer, so as to optimize >>> interleaved reads and writes. >> >> I think it's fine if the flush to the file is optional, as long as >> this is clearly documented. However, the semantics of interleaving >> reads and writes, with and without seek calls in between, should be >> well-defined and correct/useful, so that it behaves the same >> regardless of the buffer size. > > I don't know how much of the stdio will be wrapped or replaced, but, FWIW, > the C89 Standard, as described by Plauger & Brodie, requires a > position-setting operation between writes and reads: one of fflush, fseek, > fsetpos, or rewind. Same for reads and writes unless the read set EOF. We're not wrapping *any* of stdio -- we're wrapping raw Unix syscalls (or Windows APIs). The problem with the C89 standard is that if you forget this operation, the behavior is undefined, and I have seen compliant implementations that would segfault in this case. That's unacceptable for Python, and one of the reasons to bypass stdio completely. (Other reasons include the absence of standardized APIs to inspect the buffer, change buffering after starting I/O, peek ahead in the buffer, seek within the buffer without flushing, etc.) >> Ditto for the flush call currently implied by a seek -- if you can >> satisfy the seek by moving where you are in the buffer without >> flushing, that's fine IMO, but it should be well documented. >> >> It should also be documented that a flush still *may* occur, of course. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] [PATCH] Allow Python to build on MIPS Targets
When the merging of the libffi3 branch took place in March, it broke the logic in configure and fficonfig.py.in to deal with MIPS architecture, specifically differentiating in which files to include for MIPS_IRIX versus MIPS_LINUX. I've re-added that logic based on the older code, and adjusted a few things to deal with the new format. I just tested this on my QEMU instance of a MIPSEL Linux install, and works successfully. Before, it died with the error noted here: http://bugs.python.org/issue4305 , when attempting to reference a non-existent array member in fficonfig.py.in, for the MIPS target. (Rather than MIPS_LINUX or MIPS_IRIX, like the file wants) I've attached the patch here and on the following bug. It's based off the following svn checkout: Path: . URL: http://svn.python.org/projects/python/trunk Repository Root: http://svn.python.org/projects Repository UUID: 6015fed2-1504-0410-9fe1-9d1591cc4771 Revision: 68358 Node Kind: directory Schedule: normal Last Changed Author: marc-andre.lemburg Last Changed Rev: 68344 Last Changed Date: 2009-01-05 13:43:35 -0600 (Mon, 05 Jan 2009) Thanks. mips-ffi.patch Description: Binary data -- Mark Miller m...@mirell.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] another Python Bug Day?
If there's going to be another bug day, I'd like to see the problem of getting patches from the bug tracker into Python addressed in some way. It's kinda frustrating to work on things and not actually get to close any issues because there are not enough people with commit access taking part. It'd also be nice if there could be some committers around on IRC to have fast interactions with or perhaps to coordinate things (maybe asking for people to work on specific bugs, or letting people know whether a particular solution to an issue is likely to be accepted before they work on it). Schiavo Simon ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] another Python Bug Day?
On Monday 05 January 2009 23:48:13 Malte Helmert wrote: > For people who are not core developers but would still like to > contribute, the Bug Days are quite exciting events. It would be great if > they could keep going. As a not core developer, I would like to know what exactly that means. ;) Uli ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
