fixedint.py enhanced for auto-coercion (fixed-width python integers)
Hi Dan,
I find that when doing bit-twiddling in pure Python,
fixed-width integer support is an extremely handy
capability to have in Python regardless of what
the apologists (for its absence) say.
I added some stuff to fixedint.py to make
>>> x=SByte(80)
>>> x+200
fixedint.SignedType(8)(24)
the above work. Perhaps you can review the
code to see if there are any major flaws in it?
Right after I started using it, I realized
there has to be a lot more thought put into
the conventions for the coecion rules. What
should
>>> x=SByte(80)
>>> 200+x
return for example... ?
- START OF CODE -
import operator
def _toFixedUnsigned(n, b):
"Truncate n to a b-bit unsigned long."
return n & ((1L << b) - 1)# bitmask of b 1's
def _toFixedSigned(n, b):
"Truncate n to a b-bit signed long."
result = _toFixedUnsigned(n, b)
if result >= (1L << b - 1): # More than "maxint"?
result -= 1L << b # Then wrap around.
return result
class _Integer(object):
"Abstract base class for SignedType and UnsignedType."
# Numeric conversions
def __long__(self):
return self._value
def __int__(self):
return int(self._value)
def __float__(self):
return float(self._value)
def __nonzero__(self):
return self._value != 0
# String conversions.
def __str__(self):
return str(self._value)
# Arithmetic
def __pos__(self):
return self
def __neg__(self):
return type(self)(-self._value)
def __add__(self, other):
if isinstance(other, type(self)):
return type(self)(self._value + other._value)
else:
return type(self)(self._value + self.__class__(other)._value)
def __sub__(self, other):
if isinstance(other, type(self)):
return type(self)(self._value - other._value)
else:
return type(self)(self._value - self.__class__(other)._value)
def __mul__(self, other):
if isinstance(other, type(self)):
return type(self)(self._value * other._value)
else:
return type(self)(self._value * self.__class__(other)._value)
def __floordiv__(self, other):
if isinstance(other, type(self)):
return type(self)(self._value // other._value)
else:
return type(self)(self._value // self.__class__(other)._value)
def __mod__(self, other):
if isinstance(other, type(self)):
return type(self)(self._value % other._value)
else:
return type(self)(self._value % self.__class__(other)._value)
def __divmod__(self, other):
return self // other, self % other
# Relational
def __cmp__(self, other):
return cmp(long(self), other)
# Bit-bashing
def __lshift__(self, other):
return type(self)(self._value << other)
def __rshift__(self, other):
return type(self)(self._value >> other)
def __invert__(self):
return type(self)(~self._value)
def __and__(self, other):
if isinstance(other, type(self)):
return type(self)(self._value & other._value)
else:
return type(self)(self._value & self.__class__(other)._value)
def __or__(self, other):
if isinstance(other, type(self)):
return type(self)(self._value | other._value)
else:
return type(self)(self._value | self.__class__(other)._value)
def __xor__(self, other):
if isinstance(other, type(self)):
return type(self)(self._value ^ other._value)
else:
return type(self)(self._value ^ self.__class__(other)._value)
_utypes = {}
def UnsignedType(bits):
"Returns a fixed-width unsigned int type with the given number of bits."
if bits in _utypes:
return _utypes[bits]
else:
class unsigned(_Integer):
__doc__ = '%d-bit unsigned integer type' % bits
def __init__(self, value):
self._value = _toFixedUnsigned(value, bits)
def __repr__(self):
return 'fixedint.UnsignedType(%d)(%d)' % (bits, self._value)
return unsigned
Byte = UnsignedType(8)
UShort = UnsignedType(16)
UInt = UnsignedType(32)
ULong = UnsignedType(64)
_stypes = {}
def SignedType(bits):
"Returns a fixed-width signed int type with the given number of bits."
if bits in _stypes:
return _stypes[bits]
else:
class signed(_Integer):
__doc__ = '%d-bit signed integer type' % bits
def __init__(self, value):
self._value = _toFixedSigned(value, bits)
def __repr__(self):
return 'fixedint.SignedType(%d)(%d)' % (bits, self._value)
return signed
SByte = SignedType(8)
Short = SignedType(16)
Int = SignedType(32)
Long = SignedType(64)
--
http://mail.python.org/mailman/listinfo/python-list
Re: [silly] Does the python mascot have a name ?
Steve wrote: > umm, was just wondering, does the python mascot have a name ? We are naming > the > conference rooms in our office you see :o). > > Also, is there a place I could get some neat, good quality pics of the python > ? > > - steve The Python mascot is called Odi. http://mail.python.org/pipermail/python-list/2003-September/185612.html -- It's called DOM+XHR and it's *NOT* a detergent! -- http://mail.python.org/mailman/listinfo/python-list
Tabs are evil, end of discussion. (Re: Tabs versus Spaces in Source Code)
Harry George wrote: > This has been discussed repeatedly, and the answer is "If you only > work alone, never use anyone else's code and no one ever uses your > codes, then do as you please. Otherwise use tab-is-4-spaces." > > When you do Agile Programming with people using emacs, vim, nedit, > xedit, wordpad, eclipse, and who knows what else, the 4-spaces rule is > necessary for survival. > > The reason is simple: People get confused, and accidentally get the > wrong tab indents when they move among editors or among settings on > the same editor. In most languages this is an irritation, requiring > some cleanup. In Python it is a disaster requiring re-inventing the > coded algorithms. 1. Tabs as 8 spaces just take up way too much horizontal space, so you can't use 8-space tabs... 2. BUT... you can't use any other value (not even 4)... !! WHY?? Because if you do, you will screw up display using /something as basic as cat, less, more (and many other unix utilities where the historical assumption that tabs are 8 spaces is hardcoded)! DOES ANYONE NEED ANY REASON MORE COMPLICATED THAN THE ABOVE TO JUST *NOT* USE TABS?? Yet ANOTHER proof that tabs are evil: 3. If tabs weren't around, we wouldn't have all these time-wasting threads on tabs vs. spaces, or on how many spaces a tab should represent. Tabs were an unnecessary Rube Goldberg invention misguidedly carried over from the typewriter era. They are the appendix of text editors. Just because they're there doesn't necessarily mean they serve any (even remotely) useful purpose. -- It's called DOM+XHR and it's *NOT* a detergent! -- http://mail.python.org/mailman/listinfo/python-list
Tabs are *EVIL*, end of discussion. (Re: Tabs versus Spaces in Source Code)
Please... just stop this senseless defense of a Rube-Goldberg feature. There will NEVER be a universal agreement on whether tabs should be 2, 3, 4 or 8 spaces in width, and this causes endless tweaking of editor settings (a *humongous* waste of time) to handle source code made by other programmers with different settings. And I, for the life of me, have never remembered getting any source code to display properly by fiddling with my text editor's (the very popular SciTE) tab settings. 4, 8, 3, 2, it doesn't matter. *Nothing* has ever made someone's tab-infested source code display completely cleanly. Nearly a third of my coding time seems to have been spent (read:wasted) trying to reformat some unenlightened tab user's source code to read comprehensibly. 1. Tabs as 8 spaces just take up too much horizontal area 2. But you can't use any other value because if you do, you will screw up display using cat/less/more !! DOES ANYONE NEED ANY REASON MORE COMPLICATED THAN THE ABOVE TO JUST *NOT* USE TABS??!???!??!!!?? Don't be evil - always configure your editor to convert tabs to true spaces. -- It's called DOM+XHR and it's *NOT* a detergent! -- http://mail.python.org/mailman/listinfo/python-list
Re: Web framework to recommend (don't use one, use Spyce instead)
Jacky wrote: > Hi all, > > I just started learning Python and would like to starting writing some > web-based applications with Python. > > I did have pretty much experience with doing so with PHP and Java, but > Python seems a bit different for me. > > Do you guys have some good web framework to recommend? (I don't want to > use CGI mode) > > Thanks a lot. > > -- > Jacky Spyce is probably the most underappreciated Python web solution out there. If you don't want the hassle of a framework's learning curve, Spyce lets you do PHP/JSP/ASP style coding using what you already know about Python and not much else. It is also more powerful than PHP because it supports features such as custom tags (ala JSP) and others. Check out the Wikipedia article below: http://en.wikipedia.org/wiki/Spyce The important thing to note is that you can transparently use traditional ASP, JSP style angled brackets <% and %> and not the confusing [[, ]] that Spyce documentation defaults to. I believe this is what may have turned many people (who are not aware of the more standard alternative) off from using Spyce. I however, disagree with the assertion in the wikipedia article that Spyce is easier to set up than PHP... PHP is just as easy to set up as Spyce, if not easier... -- It's called DOM+XHR and it's *NOT* a detergent! -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs are *MISUNDERSTOOD*, *EVIL* AND *STUPID*, end of discussion. (Re: Tabs versus Spaces in Source Code)
If tabs are easily misunderstood, then they are a MISfeature and they need to be removed. >From the Zen of Python: "Explicit is better than implicit..." "In the face of ambiguity, refuse the temptation to guess..." "Special cases aren't special enough to break the rules..." -- It's called DOM+XHR and it's *NOT* a detergent! -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs are EVIL *and* STUPID, end of discussion. (Re: Tabs versus Spaces in Source Code)
achates wrote: >> Andy Sy wrote: >> Don't be evil - always configure your editor to >> convert tabs to true spaces. > > Yet another space-indenter demonstrates that problem actually lies with > people who think that tab == some spaces. Wrong. I am completely aware that an editor configured to convert tabs to true spaces will not always replace a tab into the same number of space characters. If you understood what I meant you'd realize that it meant: "Use the tab key if you have to (4,8,3,2... whatever...), but /always/ have your editor convert them to true spaces, so they can display properly - *without need for tweaks* - on any display medium and on anyone's program. The fact that a tab character doesn't necessarily equal a constant spaces is what makes things EVEN MORE CONFUSING. Cheez... some people just love complexity for its own sake... What earthly benefit is there anyway to mixing tabs and spaces??!? Now... if you say you SHOULDN'T mix tabs and spaces (indeed this is generally regarded as a BAD idea esp. in Python code), then WHAT THE HECK do you need to use tab characters in the source code for anyway (besides saving a measly few bytes) ??!? Tab characters are EVIL *AND* STUPID. > Sorry to hear that. You should try using an editor that's easier for > you. I am *most certainly* NOT giving SciTE up... I've spent years and years looking for the perfect editor, and I've found it with SciTE. Scite and all its cool features are NOT the problem. One single thing is: Tab characters in source code popping up like so many unsightly zits. -- It's called DOM+XHR and it's *NOT* a detergent! -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs are *MISUNDERSTOOD*, *EVIL* AND *STUPID*, end of discussion. (Re: Tabs versus Spaces in Source Code)
Peter Decker wrote: > On 5/17/06, Andy Sy <[EMAIL PROTECTED]> wrote: > >> If tabs are easily misunderstood, then they are a MISfeature >> and they need to be removed. > > I don't seem to understand your point in acting as a dictator. > Therefore, you are a MISfeature and need to be removed. Is the above an example of how a tab-user exercises 'logic'...? Besides, I'm not the only dictator here... there are also the: 4-space tabs dictators... 8-space tabs dictators... etc... -- It's called DOM+XHR and it's *NOT* a detergent! -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs versus Spaces in Source Code
Peter Decker wrote: > Spaces look like crap, too, when using proportional fonts. ... and people who would even think that using proportional fonts for viewing/editing source code is anywhere remotely near being a good idea ... That's an even more advanced version of the i-think-tabs-are-good disease... LOL! -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs are *MISUNDERSTOOD*, *EVIL* AND *STUPID*, end of discussion. (Re: Tabs versus Spaces in Source Code)
Peter Decker wrote: > On 5/17/06, Andy Sy <[EMAIL PROTECTED]> wrote: >> Peter Decker wrote: >>> On 5/17/06, Andy Sy <[EMAIL PROTECTED]> wrote: >>> >>>> If tabs are easily misunderstood, then they are a MISfeature >>>> and they need to be removed. >>> I don't seem to understand your point in acting as a dictator. >>> Therefore, you are a MISfeature and need to be removed. >> Is the above an example of how a tab-user exercises 'logic'...? > > Uh, I should know better than to try to educate, but FYI: using the > same argument construction and having it reach an invalid conclusion > suffices to show that the original construction is invalid, and thus > the original conclusion is suspect. I guess this *REALLY* is how a misguided tab user exercises his 'logic': Syntax replication (e.g. so-called 'argument construction') is enough, semantics don't matter. ROTFLMAO! -- It's called DOM+XHR and it's *NOT* a detergent! -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs are *EVIL* AND *STUPID*, NOT 'misunderstood' (Re: Tabs versus Spaces in Source Code)
achates wrote: > Andy Sy > >> I guess this *REALLY* is how a misguided tab user exercises his 'logic': >> Syntax replication (e.g. so-called 'argument construction') is enough, >> semantics don't matter. > > That's quite amusing.. you've unwittingly stumbled on a pretty concise > statement of Hilbert's first postulate of formal logic, proved by Godel > in 1930.. > >> ROTFLMAO! > > Indeed. Too bad that only applies to /statements phrased in formal logic/, not to everyday statements expressed in a human language. Only someone who has run out of sensible arguments or a disingenuous sophist would try to extend this so-called postulate the way Peter and you did. Really... if you *actually* believed that Peter's argument had merit and he was not merely being facetious, I guess I rest my case regarding tab users and their 'logical prowess'. LMAO again. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs are EVIL *and* STUPID, end of discussion. (Re: Tabs versus Spaces in Source Code)
Sybren Stuvel wrote: >> then WHAT THE HECK do you need to use tab characters in the source >> code for anyway (besides saving a measly few bytes) ??!? > > To separate layout (how much indentation is used) from semantics (how > many intentation levels). Like I said, you'll *NEVER* get that fancy shmancy 'semantic indentation' idea to work properly in the most basic utilities which have the 8-space tabs assumption hardcoded in them. Code with anything other than 8-space tabs will *NEVER* display properly using everyday unix utilities such as less and cat. But then, 8-space tabs are just too wide to be practical, thus the simple conclusion I have reached: JUST STOP USING THEM. Heck, all those who actually believe that make's requirement of an invisible tab as a 'semantic' marker was a good idea raise their hands...! >> Tab characters are EVIL *AND* STUPID. > > And someone who needs to resort to all-caps words (which many consider > shouting) needs to relax and use proper arguments. I know when I'll be able to relax... when I no longer need to waste time dealing with those stupid tabs in source code!!! ;-) -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs versus Spaces in Source Code ('semantic' vs. arbitrary indentation)
achates wrote:
> Andy Sy:
>> Code with anything other than 8-space tabs will *NEVER* display
>> properly using everyday unix utilities such as less and cat.
>
> less -x does what you want.
>
Ok, that tip certainly counts for something. This is
definitely going to make viewing tabbed code suck much
less (although you still have to guess the tab setting
using trial and error).
Next major objection then, how can one practically use 'tabs as
semantic indentation' without screwing up formatting of code like
the below??
def sqlcall():
cursor.execute('select id, item, amount, field4, field5, field6'+
'from table1 where amount>100')
... if you change the tabsize then the 3rd line will no longer
properly align with the start of the quote in the 2nd line.
The 3rd line makes use of _arbitrary_, not semantic indentation.
Because you cannot count on indentation to be semantics-driven on every
single line, you _will_ end up mixing semantic and arbitrary indentation
and thus the whole notion of being able to use tabs as 'semantic
indentation' is *still untenable*.
There is JUST NO PRACTICAL USE FOR TABS.
--
It's called DOM+XHR and it's *NOT* a detergent!
--
http://mail.python.org/mailman/listinfo/python-list
Re: Tabs versus Spaces in Source Code (semantic vs. arbitrary indentation)
Ed Singleton wrote: > On 5/15/06, Brian Quinlan <[EMAIL PROTECTED]> wrote: >> The problem with tabs is that people use tabs for alignment e.g. >> >> def foo(): >>->query = """SELECT * >>-> -> -> FROM sometable >>-> -> -> WHERE condition""" >> >> Now I change my editor to use 8-space tabs and the code is all messed >> up. Of course, a very disciplined group of people could be trained to >> never use tabs except to align with the current block level but, in >> practice, that doesn't work. Therefore tabs are bad. > > def foo(): >->query = """SELECT * >-> ...FROM sometable >-> ...WHERE condition""" > > That would solve it. Tabs for indentation, spaces for spacing. > > Ed Ok, this is a somewhat workable solution. Cons: 1) You have to be more conscientious regarding how many tabs you use at the beginning of a line. If your text editor does not display tabs explicitly (SciTE can), it can be a *REAL* hassle. 2) Because you have to use all pure spaces after the proper # of tabs, you will often end up having to type a lot of them compared to if your tab key generated pure spaces. Pro: 1) Happily, you do get your 'semantic indentation' so people can dynamically change the indentation-size they want to view your code with. You do need everyone to understand 1 thing: NEVER use tab characters (and consequently the tab key) for anything EXCEPT semantic indentation. Big question though: is the above guaranteed to work nicely in all situations in python? Also, in free-format languages like C, Java, C#, the temptation to mix semantic and arbitrary indentation might be just too great for sloppy programmers. If anyone wants to use tabs, I think the above is the ONLY right way to use them and it also happily eliminates any arguments over how many spaces you should use for your tab setting. If ALL tab users followed this convention, I will happily consider myself agnostic... ;-) Now, on to the next holy war... date formats ANY OTHER FORMAT BESIDES ISO MMDD (but it's ok to put dashes in between or use word MMM instead of numerical MM) IS *EVIL* AND *MISGUIDED*! -- It's called DOM+XHR and it's *NOT* a detergent! -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs versus Spaces in Source Code ('semantic' vs. arbitrary indentation)
Carl J. Van Arsdall wrote:
>> Next major objection then, how can one practically use 'tabs as
>> semantic indentation' without screwing up formatting of code like
>> the below??
>>
>>
>> def sqlcall():
>> cursor.execute('select id, item, amount, field4, field5, field6'+
>> 'from table1 where amount>100')
>>
>>
> Why couldn't you tab your third line over as close as possible to the
> start of the quote then use a couple spaces? Then the tabs would work
> just fine and you could still have your pretty line.
This will break if someone tries to view my code using different
tab settings from the one I'm using.
--
It's called DOM+XHR and it's *NOT* a detergent!
--
http://mail.python.org/mailman/listinfo/python-list
The ONE TRUE WAY to use tabs (Re: Tabs versus Spaces in Source Code)
achates wrote:
> Yeah - we've got to the repeating ourselves stage.
Actually a couple of the responses on this newsgroup
have settled the question for me. I did learn something
new by engaging in this holy war.
Tabs need not be evil, but ONLY if they are used in one
particular way:
If you really must use tabs, use them *ONLY* for 'semantic'
indentation and use pure spaces when you need arbitrary
indentation (e.g. arbitrary spacing).
PHP Example
===
function xyz() {
->print "This is a really really really long line that I'd ".
-> "like to extend to the one down below while preserving ".
-> "ease of readability by aligning the start of the string".
-> "lines. I use tabs to reflect syntactical (e.g. semantic) ".
-> "indentation, but use spaces for arbitrary indentation.\n\n".;
->while (10) {
->->print "This code will align properly no matter what tabsize setting ".
->-> "the reader uses, and is the only real benefit of using tab ".
->-> "characters instead of pure spaces.\n\n";
}
I did some basic tests, and it looks like this style should also
work for Python code.
THIS IS THE *SINGLE* CORRECT WAY TO USE TABS IN CODE! ANYTHING
ELSE WILL BE A PAIN FOR PEOPLE WITH TABSIZE SETTINGS DIFFERENT
FROM YOURS!!
> But that's the problem with this issue: it's really hard to get the
> space-indenters to actually think about it and to address what is being
> said. Every time it comes up, there's always a few people trying to
> explain why tabs give are a good idea, facing a whole raft of others
> spouting stuff like:
Most of the tab-indenters have the same attitude. But I did get ALL
of my points against tabs addressed this time. And thank you to those
people including you for the 'less -x' tip.
> But unfortunately the situation is worse than that: tab indentation
> needs to be actively defended.
A world where everyone uses pure spaces would be far far far better
than the current situation where tab users can't even decide what
the universal tabsize should be and whose code alignment breaks
on different tabsize settings.
However, a world where EVERYONE who uses tabs strictly practice the
ONE TRUE TAB WAY would be a *slightly* better place than one where
everyone used pure spaces.
And remember, the ONE TRUE TAB WAY does not come for free and involves
a certain amount of tedium and attention. It will be impractical on
most simple text editors. For most people, I frankly don't think the
minor benefits are worth it.
> Unlikely perhaps. I hope so. It's a cruel irony that Python's creator
> didn't appreciate the benefits that tab indentation would bring to his
> own language - the only major language in which indentation levels
> actually have semantic significance.
You might want to run those benefit/s/ by me again, because the SINGLE
benefit I can still see to using tabs is so that people who have
different indentation width preferences can view code according to
the way they want. And remember, this benefit will ONLY occur
IF people stick to using the ONE TRUE TAB WAY outlined above.
Any other method of tabbing would just be worse than a pure-spaces
world.
--
It's called DOM+XHR and it's *NOT* a detergent!
--
http://mail.python.org/mailman/listinfo/python-list
Re: The ONE TRUE WAY to use tabs (if you must...)
Andy Sy wrote:
> Actually a couple of the responses on this newsgroup
> have settled the question for me. I did learn something
> new by engaging in this holy war.
>
>
> Tabs need not be evil, but ONLY if they are used in one
> particular way:
>
> If you really must use tabs, use them *ONLY* for 'semantic'
> indentation and use pure spaces when you need arbitrary
> indentation (e.g. arbitrary spacing).
>
> PHP Example
> ===
>
> function xyz() {
> ->print "This is a really really really long line that I'd ".
> -> "like to extend to the one down below while preserving ".
> -> "ease of readability by aligning the start of the string".
> -> "lines. I use tabs to reflect syntactical (e.g. semantic) ".
> -> "indentation, but use spaces for arbitrary indentation.\n\n".;
> ->while (10) {
> ->->print "This code will align properly no matter what tabsize setting ".
> ->-> "the reader uses, and is the only real benefit of using tab ".
> ->-> "characters instead of pure spaces.\n\n";
> }
>
>
>
> I did some basic tests, and it looks like this style should also
> work for Python code.
>
>
> THIS IS THE *SINGLE* CORRECT WAY TO USE TABS IN CODE! ANYTHING
> ELSE WILL BE A PAIN FOR PEOPLE WITH TABSIZE SETTINGS DIFFERENT
> FROM YOURS!!
Also... remember that the 'ONE TRUE WAY' essentially involves *mixing*
tabs and spaces for indentation with all the objections that that
entails... (although like mentioned above, it should work with Python,
at least in the simple cases i've tried)
Frankly, the case for tab usage is not that compelling...
--
It's called DOM+XHR and it's *NOT* a detergent!
--
http://mail.python.org/mailman/listinfo/python-list
