Re: [Python-Dev] PyOS_InputHook enhancement proposal
Aahz wrote: On Thu, Dec 09, 2004, Michiel Jan Laurens de Hoon wrote: My suggestion is therefore to replace PyOS_InputHook by two functions PyOS_AddInputHook and PyOS_RemoveInputHook, and let Python keep track of which hooks are installed. This way, an extension module can add a hook function without having to worry about other extension modules trying to use the same hook. Any comments? Would I need to submit a PEP for this proposal? Because this is only for the C API, your best bet is to write a patch and submit it to SF. If people whine or it gets rejected, then write a PEP. I did modify the readline module that hooks this and can call back to a Python function. There are also methods for installing and removing the Python function. I did this for a different reason. I need Python signal handlers to run, and they don't run when the execution path is currently in some C code (such as readline). The hook forces the interpreter to run, and check for signals as a side effect. Using this I can be sitting in raw_input(), or interactive mode, and signal handlers are still run. If you want it, let me know. Actually, the modded readline module is part of pyNMS, on sourceforge. -- \/ \/ (O O) -- oOOo~(_)~oOOo Keith Dart <[EMAIL PROTECTED]> vcard: <http://www.kdart.com/~kdart/kdart.vcf> public key: ID: F3D288E4 URL: <http://www.kdart.com/~kdart/public.key> ___ 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] Re: Re: 2.4 news reaches interesting places
A.M. Kuchling wrote: On Sun, Dec 12, 2004 at 03:32:03PM -0200, Carlos Ribeiro wrote: Of course, the point here is not Perl-bashing. The point here is that we should be able to "sell" Python better than we do now, even without the need to resort to such poor measures. I'm sure the Python community does have good & creative people that can write a good "selling" FAQ for Python, emphasizing the main points of the language. No one disagrees that Python needs better marketing material. At the last PyCon a group of people sat down in a pydotorg BoF and agreed that yes, we do need a management-friendly marketing site, and that we could put it on a separate hostname (something.python.org) so that the current www.python.org wouldn't have to be changed. However, no one has actually sat down and written such a site, or even outlined it. Let me encourage you to go ahead and do that. You could draft the outline on a Wiki page, and then later figure out an attractive design and organization for a new site. Whatever it looks like, it should probably run on Zope plus Plone. 8-) You know... eat your own dog food. 8-) The kind folks over at Zettai! have provided some space for me. Perhaps they will be glad to host the main Python site, as well? -- \/ \/ (O O) -- oOOo~(_)~oOOo-------- Keith Dart <[EMAIL PROTECTED]> vcard: <http://www.kdart.com/~kdart/kdart.vcf> public key: ID: F3D288E4 URL: <http://www.kdart.com/~kdart/public.key> ___ 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] Is PEP 237 final -- Unifying Long Integers and Integers
Guido van Rossum wrote: >On 6/17/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > > >>IIRC, there was a decision to not implement phase C and to keep the >>trailing L in representations of long integers. >> >> > >Actually, the PEP says phase C will be implemented in Python 3.0 and >that's still my plan. > > > >>If so, I believe the PEP can be marked as final. We've done all we're >>going to do. >> >> > >For 2.x, yes. I'm fine with marking it as Final and adding this to PEP >3000 instead. > > > I am very concernced about something. The following code breaks with 2.4.1: fcntl.ioctl(self.rtc_fd, RTC_RD_TIME, ...) Where RTC_RD_TIME = 2149871625L In Python 2.3 it is -2145095671. Actually, this is supposed to be an unsigned int, and it was construced with hex values and shifts. Now, with the integer unification, how is ioctl() supposed to work? I cannot figure out how to make it work in this case. I suppose the best thing is to introduce an "unsignedint" type for this purpose. As it is right now, I cannot use 2.4 at all. -- -- ~ Keith Dart <[EMAIL PROTECTED]> public key: ID: F3D288E4 = begin:vcard fn:Keith Dart n:Dart;Keith email;internet:[EMAIL PROTECTED] tel;work:408-249-1830 tel;fax:408-249-1830 tel;home:408-296-5806 x-mozilla-html:FALSE version:2.1 end:vcard ___ 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] Is PEP 237 final -- Unifying Long Integers and Integers
On Sat, 18 Jun 2005, Michael Hudson wrote: > > The shortest way I know of going from 2149871625L to -2145095671 is > the still-fairly-gross: > >>>> v = 2149871625L >>>> ~int(~v&0x) > -2145095671 > >> I suppose the best thing is to introduce an "unsignedint" type for this >> purpose. > > Or some kind of bitfield type, maybe. > > C uses integers both as bitfields and to count things, and at least in > my opinion the default assumption in Python should be that this is > what an integer is being used for, but when you need a bitfield it can > all get a bit horrible. > > That said, I think in this case we can just make fcntl_ioctl use the > (new-ish) 'I' format argument to PyArg_ParseTuple and then you'll just > be able to use 2149871625L and be happy (I think, haven't tried this). Thanks for the reply. I think I will go ahead and add some extension types to Python. Thankfully, Python is extensible with new objects. It is also useful (to me, anyway) to be able to map, one to one, external primitives from other systems to Python primitives. For example, CORBA and SNMP have a set of types (signed ints, unsigned ints, etc.) defined that I would like to interface to Python (actually I have already done this to some degree). But Python makes it a bit more difficult without that one-to-one mapping of basic types. Having an unsigned int type, for example, would make it easier to interface Python to SNMP or even some C libraries. In other words, Since the "Real World" has these types that I must sometimes interface to, it is useful to have these same (predictable) types in Python. So, it is worth extending the basic set of data types, and I will add it to my existing collection of Python extensions. Therefore, I would like to ask here if anyone has already started something like this? If not, I will go ahead and do it (if I have time). -- -- ~ Keith Dart <[EMAIL PROTECTED]> public key: ID: F3D288E4 = ___ 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] Is PEP 237 final -- Unifying Long Integers and Integers
On Sun, 19 Jun 2005, Josiah Carlson wrote:
>
> Keith Dart <[EMAIL PROTECTED]> wrote:
>
>> Therefore, I would like to ask here if anyone has already started
>> something like this? If not, I will go ahead and do it (if I have time).
>
> If all you need to do is read or write C-like types to or from memory,
> you should spend some time looking through the 'struct' module if you
> haven't already.
I know about 'struct'. However, it will just convert to Python "native"
types. C unsigned become Python longs.
u = struct.pack("I", 0xfffe)
struct.unpack("I", u)
(4294967294L,)
In SNMP, for example, a Counter32 is basically an unsigned int, defined
as "IMPLICIT INTEGER (0..4294967295)". One cannot efficiently translate
and use that type in native Python. Currently, I have defined an
"unsigned" type as a subclass of long, but I don't think that would be
speed or storage efficient.
On the other hand, adding my own type won't help with the ioctl()
problem, since it won't know about it.
--
-- ~
Keith Dart <[EMAIL PROTECTED]>
public key: ID: F3D288E4
=
___
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] Is PEP 237 final -- Unifying Long Integers and Integers
On Mon, 20 Jun 2005, Guido van Rossum wrote: > [Keith Dart] >> In SNMP, for example, a Counter32 is basically an unsigned int, defined >> as "IMPLICIT INTEGER (0..4294967295)". One cannot efficiently translate >> and use that type in native Python. Currently, I have defined an >> "unsigned" type as a subclass of long, but I don't think that would be >> speed or storage efficient. > > In my experience you can just use Python longs whenever a C API needs > an "unsigned" long. There's no need to subtype, and your assumption > that it would not be efficient enough is mistaken (unless you are > manipulating arrays with millions of them, in which case you should be > using Numeric, which has its own types for this purpose). (Want to > argue about the efficiency? Write a typical use case and time it.) Ok, I'll take your word for it. I don't have any performance problems now, in my usage, but I wanted to make sure that Python "shows well" in certain "bake offs" ;-) > By far the easiest way to do arithmetic mod 2**32 is to just add "& > 0x" to the end of your expression. For example, simulating the > effect of multiplying an unsigned long by 3 would be x = (x * 3) & > 0x. But then I wouldn't know if it overflowed 32 bits. In my usage, the integer will be translated to an unsigned (32 bit) integer in another system (SNMP). I want to know if it will fit, and I want to know early if there will be a problem, rather than later (at conversion time). One of the "selling points" of Python in previous versions was that you would get an OverFlowError on overflow, where other languages did not (they overflowed silently). So I subclassed long in 2.3, to get the same overflow exception: class unsigned(long): floor = 0L ceiling = 4294967295L bits = 32 _mask = 0xL def __new__(cls, val): return long.__new__(cls, val) def __init__(self, val): if val < self.floor or val > self.ceiling: raise OverflowError, "value %s out of range for type %s" % (val, self.__class__.__name__) def __repr__(self): return "%s(%sL)" % (self.__class__.__name__, self) def __add__(self, other): return self.__class__(long.__add__(self, other)) ... Again, because I want to catch the error early, before conversion to the external type. BTW, the conversion is done in pure Python (to a BER representation), so using a C type (via ctypes, or pyrex, or whatever) is not possible. > If there is a problem with ioctl() not taking long ints, that would be > a bug in ioctl, not a lacking data type or a problem with long ints. That must be it, then. Shall I file a bug somewhere? -- -- ~ Keith Dart <[EMAIL PROTECTED]> public key: ID: F3D288E4 = ___ 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] Is PEP 237 final -- Unifying Long Integers and Integers
On Mon, 20 Jun 2005, Keith Dart wrote: > But then I wouldn't know if it overflowed 32 bits. In my usage, the > integer will be translated to an unsigned (32 bit) integer in another > system (SNMP). I want to know if it will fit, and I want to know early if > there will be a problem, rather than later (at conversion time). > > class unsigned(long): I guess I just clarify this more. My "unsigned" type really is an object that represents a type of number from the external system. Previously, there was a nice, clean mapping between external types and Python types. Now there is not so clean a mapping. Not that that makes it a problem with Python itself. However, since it is sometimes necessary to interface to other systems with Python, I see no reason why Python should not have a full set of built in numeric types corresponding to the machine types and, in turn, other system types. Then it would be easier (and probaby a bit faster) to interface to them. Perhaps Python could have an "integer" type for long/int unified types, and just "int" type as "normal" integers? -- -- ~~~~~ Keith Dart <[EMAIL PROTECTED]> public key: ID: F3D288E4 = ___ 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] Is PEP 237 final -- Unifying Long Integers and Integers
On Tue, 21 Jun 2005, Guido van Rossum wrote:
[two messages mixed]
> Huh? C unsigned ints don't flag overflow either -- they perform
> perfect arithmetic mod 2**32.
I was talking about signed ints. Sorry about the confusion. Other
scripting languages (e.g. perl) do not error on overflow.
>
>> In my usage, the
>> integer will be translated to an unsigned (32 bit) integer in another
>> system (SNMP). I want to know if it will fit, and I want to know early if
>> there will be a problem, rather than later (at conversion time).
>
> So check if it is >= 2**32 (or < 0, of course).
That's exactly what I do. ;-) The "unsigned" subclass of long is part of
the API, and checks the range when it is created (and they get created
implicitly when operated on).
> (a) Stop worrying about speed. The overhead of a single Python
> bytecode execution is probably more than the cost of an integer
> operation in most cases.
I am not thinking of the integer operation, but the extra Python
bytecode necessary to implement the extra checks for overflow.
>> Again, because I want to catch the error early, before conversion to the
>> external type.
>
> This is a very specialized application. Your best approach is to check
> for overflow before passing into the external API -- ideally the
> wrappers for that API should do so.
> (c) The right place to do the overflow checks is in the API wrappers,
> not in the integer types.
That would be the "traditional" method.
I was trying to keep it an object-oriented API. What should "know" the
overflow condition is the type object itself. It raises OverFlowError any
time this occurs, for any operation, implicitly. I prefer to catch errors
earlier, rather than later.
> (b) I don't know what you call a "normal" integer any more; to me,
> unified long/int is as normal as they come. Trust me, that's the case
> for most users. Worrying about 32 bits becomes less and less normal.
By "normal" integer I mean the mathematical definition. Most Python users
don't have to worry about 32 bits now, that is a good thing when you are
dealing only with Python. However, if one has to interface to other
systems that have definite types with limits, then one must "hack around"
this feature. I was just thinking how nice it would be if Python had, in
addition to unified ("real", "normal") integers it also had built-in
types that could be more easily mapped to external types (the typical
set of signed, unsigned, short, long, etc.).Yes, you can check it at
conversion time, but that would mean extra Python bytecode. It seems you
think this is a special case, but I think Python may be used as a "glue
language" fairly often, and some of us would benefit from having those
extra types as built-ins.
--
-- ~
Keith Dart <[EMAIL PROTECTED]>
public key: ID: F3D288E4
=
___
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] Is PEP 237 final -- Unifying Long Integers and Integers
On Tue, 21 Jun 2005, Ron Adam wrote: > It seems to me, that maybe a single "byte_buffer" type, that can be > defined to the exact needed byte lengths and have possible other > characteristics to aid in interfacing to other languages or devices, > would be a better choice. > > Then pythons ints, floats, etc... can uses what ever internal lengths is > most efficient for the system it's compiled on and then the final result > can be stored in the 'byte_buffer' for interfacing purposes. > > It would also be a good choice for bit manipulation when someone needs > that, instead of trying to do it in an integer. > > Would something like that fulfill your need? Sounds interresting. Not exactly stright-forward. What i have now is functional, but if speed becomes a problem then this might be useful. -- -- ~~~~~ Keith Dart <[EMAIL PROTECTED]> public key: ID: F3D288E4 = ___ 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] threadsafe patch for asynchat
Barry Warsaw wrote the following on 2006-02-08 at 13:45 PST: === > Or the guy who needs to whip together an RFC-compliant minimal SMTP > server to use in unit tests of some random Python implemented mailing > list manager. Just fer instance. But still... > > > But I can't speak for how often this need comes up among users. > > Yeah, there is that. ;) === There are other, third-party, SMTP server objects available. You could always use one of those. Once the "Python egg" and PyPI improve and start widespread use perhaps the question of what is in the core library and what is not will become moot. Being a Gentoo Linux user I already enjoy having many modules available, with automatic dependency installation, on demand. So the idea of "core" library is already blurred for me. -- -- ~~~~~ Keith Dart <[EMAIL PROTECTED]> public key: ID: 19017044 <http://www.dartworks.biz/> = signature.asc Description: PGP signature ___ 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] Let's just *keep* lambda
Guido van Rossum wrote the following on 2006-02-08 at 10:07 PST: === > Note that I'm not participating in any attempts to "improve" lambda. === FWIW, I like lambda. No need to change it. Thank you. -- -- ~~~~~ Keith Dart <[EMAIL PROTECTED]> public key: ID: 19017044 <http://www.dartworks.biz/> = signature.asc Description: PGP signature ___ 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] Let's just *keep* lambda
Guido van Rossum wrote the following on 2006-02-09 at 16:27 PST: === > Since you probably won't stop until I give you an answer: I'm really > not interested in a syntactic solution that allows multi-line lambdas. === Fuzzy little lambdas, wouldn't hurt a fly. Object of much derision, one has to wonder why? Docile little lambdas, so innocent and pure Only wants to function with finality and closure. Cute little lambdas, they really are so sweet When ingested by a Python they make a tasty treat. -- -- ~~~~~ Keith Dart <[EMAIL PROTECTED]> public key: ID: 19017044 <http://www.dartworks.biz/> = signature.asc Description: PGP signature ___ 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] Let's just *keep* lambda
Greg Ewing wrote the following on 2006-02-10 at 16:20 PST: === > Although "print" may become a function in 3.0, so that this > particular example would no longer be a problem. === You can always make your own Print function. The pyNMS framework adds many new builtins, as well as a Print function, when it is installed. http://svn.dartworks.biz/svn/repos/pynms/trunk/lib/nmsbuiltins.py -- -- ~~~~~ Keith Dart <[EMAIL PROTECTED]> public key: ID: 19017044 <http://www.dartworks.biz/> = signature.asc Description: PGP signature ___ 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
