Re: sort(*, key=None, reverse=None)

[Mark Lawrence]

On 21/12/2013 07:35, Chris Angelico wrote:

On Sat, Dec 21, 2013 at 6:24 PM, Mark Lawrence  wrote:

On 21/12/2013 07:20, Devin Jeanpierre wrote:


On Fri, Dec 20, 2013 at 11:16 PM, Mark Lawrence 
wrote:


The subject refers to the list sort method given here
http://docs.python.org/3/library/stdtypes.html#list.  I believe that the
"*," bit is simply a typo, given that the docs also state "sort() accepts
two arguments that can only be passed by keyword".  Am I correct?



It's good practice in technical writing to repeat yourself: once in
the formal spec, and once in plain english. I don't see why this would
be a typo.

-- Devin



So what is it actually saying?


def func(x, y, *moreargs, foo, bar):
 pass

Any positional args after x and y will go into moreargs, so foo and
bar have to be specified by keywords. (And are mandatory, since I
didn't default them.) If moreargs isn't given a name, then additional
positional args are forbidden, but the requirements on foo and bar are
the same.

ChrisA



Thanks, you learn something new every day.  Or, at my age, you relearn 
something you've forgotten :)  Now where was I...


--
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.


Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: sort(*, key=None, reverse=None)

[Chris Angelico]

On Sat, Dec 21, 2013 at 6:59 PM, Mark Lawrence  wrote:
> Now where was I...

Australia!

ChrisA

[1] http://www.princessbride.8m.com/script.htm
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why Python is like C++

[Gregory Ewing]

Mark Lawrence wrote:

On 20/12/2013 14:19, Roy Smith wrote:


http://xkcd.com/1306/



I believe that to be a very superficial like.  They're unlike in that 
once C++ people have compiled their code they can head down to the pub, 
but Python people have to stay at work testing because the compiler 
hasn't caught all potential errors.


But it takes so much longer for the C++ people to
write their program in the first place, that the
Python people often get to the pub first anyway.
And even if they don't get to the pub at all, they
enjoy what they're doing so much that they don't
care.

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: Why Python is like C++

[Gregory Ewing]

Michael Torrie wrote:

Maybe BASIC's of the 70s.  But Not QB.  QuickBasic was a pretty
impressive compiler in its day.  Completely modern, structured language.


I may have been thinking of GW-BASIC. There was
definitely something that was pretty much an
old-school BASIC with line numbers, GOSUBS and
all that.

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: Why Python is like C++

[Chris Angelico]

On Sat, Dec 21, 2013 at 7:06 PM, Gregory Ewing
 wrote:
> Michael Torrie wrote:
>>
>> Maybe BASIC's of the 70s.  But Not QB.  QuickBasic was a pretty
>> impressive compiler in its day.  Completely modern, structured language.
>
>
> I may have been thinking of GW-BASIC. There was
> definitely something that was pretty much an
> old-school BASIC with line numbers, GOSUBS and
> all that.

GW-BASIC is what you're describing. Q-BASIC isn't the same as
QuickBasic, though. Q-BASIC had subs and functions and stuff, but it
was still, at its heart, BASIC. And you could DIM something with a
type, but normally it was the adorning suffix that determined type: A$
is a string, A% is an integer, A! (or A) is float, A# is double.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why Python is like C++

[Mark Lawrence]

On 21/12/2013 08:09, Gregory Ewing wrote:

Mark Lawrence wrote:

On 20/12/2013 14:19, Roy Smith wrote:


http://xkcd.com/1306/



I believe that to be a very superficial like.  They're unlike in that
once C++ people have compiled their code they can head down to the
pub, but Python people have to stay at work testing because the
compiler hasn't caught all potential errors.


But it takes so much longer for the C++ people to
write their program in the first place, that the
Python people often get to the pub first anyway.
And even if they don't get to the pub at all, they
enjoy what they're doing so much that they don't
care.



Having thought about this for all of 2ns I've come to the startling 
conclusion that I entirely agree with you.  I'm very biased though, 
suffering extremely badly from both C++phobia and Javaphobia.


--
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.


Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: Why Python is like C++

[Dan Stromberg]

On Fri, Dec 20, 2013 at 9:34 PM, Mark Lawrence  wrote:
> On 20/12/2013 14:19, Roy Smith wrote:
>>
>> http://xkcd.com/1306/
>>
>
> I believe that to be a very superficial like.  They're unlike in that once
> C++ people have compiled their code they can head down to the pub, but
> Python people have to stay at work testing because the compiler hasn't
> caught all potential errors.

Python should be used with static analysis (EG pylint), IMO, for
reliability.  Python should also be used, IMO, with a good set of
automated unit, integration and system tests.

C++ should use automated tests too, but is often used without because
the compilers make it almost reasonable to do without.  The compilers
tend to make it so you don't need static analysis, but it's so cheap
to use static analysis that it's a good idea to do so.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why Python is like C++

[Mark Lawrence]

On 21/12/2013 08:18, Dan Stromberg wrote:

On Fri, Dec 20, 2013 at 9:34 PM, Mark Lawrence  wrote:

On 20/12/2013 14:19, Roy Smith wrote:


http://xkcd.com/1306/



I believe that to be a very superficial like.  They're unlike in that once
C++ people have compiled their code they can head down to the pub, but
Python people have to stay at work testing because the compiler hasn't
caught all potential errors.


Python should be used with static analysis (EG pylint), IMO, for
reliability.  Python should also be used, IMO, with a good set of
automated unit, integration and system tests.



I use the Pydev plugin for Eclipse and have Pylint turned on so that it 
automatically checks my code as I type, just awesome.  To me your second 
sentence above goes without saying.  And add in anything that can help 
improve quality.  This recipe 
http://code.activestate.com/recipes/578793-more-strict-unittests-using-a-validator/ 
only went up yesterday, haven't checked it out in detail but the idea 
seems impressive.


--
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.


Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

@property simultaneous setter and getter

[Brian Bruggeman]

Is this something that would be pep-able?

https://gist.github.com/brianbruggeman/8061774

Thanks in advance.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: @property simultaneous setter and getter

[Peter Otten]

Brian Bruggeman wrote:

> Is this something that would be pep-able?
> 
> https://gist.github.com/brianbruggeman/8061774

There's no need to put such a small piece of code into an external 
repository.

> class someAwesomeClass(object):
> """ an example """
> 
> @property
> def some_attr(self, value=None):
> """
> Implementation of a setter and getter property in one
> """
> attr = "__local_attr__"
> if not hasattr(self, attr):
> setattr(self, attr, value)
> if (value != None and hasattr(self, attr)):
> setattr(self, attr, value)
> return getattr(self, attr)

If I were to implement something like this I'd probably use the old trick 
with nested functions:

def getset(f):
funcs = f()
return property(funcs.get("get"), funcs.get("set"))

class A(object):
@getset
def attr():
def get(self):
print("accessing attr")
return self._attr
def set(self, value):
print("setting attr to {}".format(value))
self._attr = value
return locals()

if __name__ == "__main__":
a = A()
a.attr = 42
print(a.attr)

This has been around awhile, but I don't see widespread adoption...

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why Python is like C++

[Christian Gollwitzer]

Am 21.12.13 09:06, schrieb Gregory Ewing:

Michael Torrie wrote:

Maybe BASIC's of the 70s.  But Not QB.  QuickBasic was a pretty
impressive compiler in its day.  Completely modern, structured language.


I may have been thinking of GW-BASIC. There was
definitely something that was pretty much an
old-school BASIC with line numbers, GOSUBS and
all that.



GW-BASIC was a weak language, but two significant characters is 
definitely too few. I think it was eight. Never used QuickBasic, I went 
Turbo Pascal instead, which had 32 significant characters.


Christian
--
https://mail.python.org/mailman/listinfo/python-list

Re: @property simultaneous setter and getter

[Steven D'Aprano]

On Fri, 20 Dec 2013 15:26:10 -0600, Brian Bruggeman wrote:

> Is this something that would be pep-able?

I don't know. What is it? I'm sure your code is the most fabulous, 
awesome and brilliant thing since Grace Hopper came up with FORmula 
TRANslation back in the 1950s, but my browser has over eighty tabs open 
at the moment, give me a reason why I ought to open one more.


> https://gist.github.com/brianbruggeman/8061774

If you aren't willing or able to spend a sentence or three explaining 
what your code does, what need it fulfils, and why it ought to be 
included in Python, you're going to have real bad time trying to persuade 
the hard-nosed, conservative core developers. Trust me, I know what I am 
talking about, I am the author of a successful PEP:

http://www.python.org/dev/peps/pep-0450/

and that was for something which already had at least two of the most 
respected core developers' support before I even started. So before you 
go to the effort of writing a PEP, how about you try to justify your 
proposal here?



-- 
Steven
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why Python is like C++

[Steven D'Aprano]

On Sat, 21 Dec 2013 05:34:51 +, Mark Lawrence wrote:

> On 20/12/2013 14:19, Roy Smith wrote:
>> http://xkcd.com/1306/
>>
>>
> I believe that to be a very superficial like.  They're unlike in that
> once C++ people have compiled their code they can head down to the pub,

Ah, the good ol' "It compiles, quick, ship it!" school of thought.


-- 
Steven
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why Python is like C++

[Steven D'Aprano]

On Sat, 21 Dec 2013 00:18:33 -0800, Dan Stromberg wrote:

> C++ should use automated tests too, but is often used without because
> the compilers make it almost reasonable to do without.

For some definition of "reasonable" that I haven't come across before. 
I'd like to see the compiler that can determine which of the following 
pseudo-code functions is buggy:


# Given the length of the shadow cast when the sun is at
# angle degrees measured from the horizontal, return the
# height of the thing casting the shadow.

def calculate_height(length:float, angle:float):float;
if not 0.0 <= angle < 90.0:
Error, "angle out of range"
if not length >= 0.0:
Error, "length cannot be negative"
return length*sin(degrees_to_radian(angle))

def calculate_height(length:float, angle:float):float;
if not 0.0 <= angle < 90.0:
error("angle out of range")
if not length >= 0.0:
error("length cannot be negative")
return length*tan(degrees_to_radian(angle))


-- 
Steven
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: @property simultaneous setter and getter

[Devin Jeanpierre]

On Sat, Dec 21, 2013 at 2:14 AM, Peter Otten <__pete...@web.de> wrote:
> If I were to implement something like this I'd probably use the old trick
> with nested functions:
>
> def getset(f):
> funcs = f()
> return property(funcs.get("get"), funcs.get("set"))
>
> class A(object):
> @getset
> def attr():
> def get(self):
> print("accessing attr")
> return self._attr
> def set(self, value):
> print("setting attr to {}".format(value))
> self._attr = value
> return locals()
>
> if __name__ == "__main__":
> a = A()
> a.attr = 42
> print(a.attr)
>
> This has been around awhile, but I don't see widespread adoption...

IMO: Because classes are the normal way of grouping functions together
in Python.

In fact, we already have an interface for these classes: the
descriptor protocol. Unfortunately it's pretty annoying to define
"properties" directly using the descriptor protocol, because its
__get__ is weird and difficult to remember how to make work correctly.
Also because the decorator making this convenient has been vanished in
python 3. ;)

class A(object):
_attr = None

@apply
class attr(object):
def __get__(self, instance, owner):
if instance is None:
return self

print "accessing attr"
return instance._attr

def __set__(self, instance, value):
print "setting attr to {}".format(value)
instance._attr = value

a = A()
a.attr
a.attr = 42


A().attr
A().attr = 3

-- Devin
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: @property simultaneous setter and getter

[Mark Lawrence]

On 21/12/2013 11:31, Steven D'Aprano wrote:

On Fri, 20 Dec 2013 15:26:10 -0600, Brian Bruggeman wrote:


Is this something that would be pep-able?


I don't know. What is it? I'm sure your code is the most fabulous,
awesome and brilliant thing since Grace Hopper came up with FORmula
TRANslation back in the 1950s, but my browser has over eighty tabs open
at the moment, give me a reason why I ought to open one more.



I was under the impression that she was more associated with COBOL but 
never mind.





https://gist.github.com/brianbruggeman/8061774


If you aren't willing or able to spend a sentence or three explaining
what your code does, what need it fulfils, and why it ought to be
included in Python, you're going to have real bad time trying to persuade
the hard-nosed, conservative core developers. Trust me, I know what I am
talking about, I am the author of a successful PEP:

http://www.python.org/dev/peps/pep-0450/

and that was for something which already had at least two of the most
respected core developers' support before I even started. So before you
go to the effort of writing a PEP, how about you try to justify your
proposal here?



Nail struck firmly on head I reckon.

--
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.


Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: Why Python is like C++

[Mark Lawrence]

On 21/12/2013 11:37, Steven D'Aprano wrote:

On Sat, 21 Dec 2013 05:34:51 +, Mark Lawrence wrote:


On 20/12/2013 14:19, Roy Smith wrote:

http://xkcd.com/1306/



I believe that to be a very superficial like.  They're unlike in that
once C++ people have compiled their code they can head down to the pub,


Ah, the good ol' "It compiles, quick, ship it!" school of thought.



Absolutely, everybody knows that successful compilation indicates bug 
free code, which is why statically typed languages are so vastly 
superior to dynamically typed ones, hence why the latter will never 
catch on.  Or do people around here know something I don't? :)


--
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.


Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: bytearray inconsistencies?

[Mark Lawrence]

On 21/12/2013 01:58, Ned Batchelder wrote:


If you have a zero, you can split on it with:
bytestring.split(bytes([0])), but that doesn't explain why find can take
a simple zero, and split has to take a bytestring with a zero in it.



Create a bytearray(range(256)) and partition it on 128.  I'd expect to 
see the original effectively cut in half with 128 as the separator.  You 
actually get the original with two empty bytearrays, which makes no 
sense to me at all.


I also looked in test_bytes.py, read as far as "XXX This is a mess" and 
promptly gave up.


--
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.


Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: Newbie question. Are those different objects ?

[Steven D'Aprano]

On Fri, 20 Dec 2013 16:00:22 +, Mark Lawrence wrote:

> On 20/12/2013 15:34, rusi wrote:

>> You are also assuming that the two horizontal lines sometimes called
>> 'equals' have something to do with something called by the same name in
>> math -- equations
>>
>>
> A good point.  Shall I write a PEP asking for a language change which
> requires that that stupid = sign is replaced by a keyword reading
> something like
> thenameonthelefthandsideisassignedtheobjectontherighthandside ?

That's an excellent idea, and I look forward to reading the PEP.



-- 
Steven
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: bytearray inconsistencies?

[Steven D'Aprano]

On Sat, 21 Dec 2013 12:29:14 +, Mark Lawrence wrote:

> Create a bytearray(range(256)) and partition it on 128.  I'd expect to
> see the original effectively cut in half with 128 as the separator.  You
> actually get the original with two empty bytearrays, which makes no
> sense to me at all.

I reckon that is a bug. Consider this smaller example:


py> ba = bytearray(range(8))
py> ba
bytearray(b'\x00\x01\x02\x03\x04\x05\x06\x07')
py> 3 in ba
True
py> ba.find(3) == ba.index(3) == ba.find(b'\x03')
True
py> ba.partition(b'\x03')
(bytearray(b'\x00\x01\x02'), bytearray(b'\x03'), bytearray(b'\x04\x05\x06
\x07'))
py> ba.partition(3)
(bytearray(b'\x00\x01\x02\x03\x04\x05\x06\x07'), bytearray(b''), bytearray
(b''))



-- 
Steven
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: bytearray inconsistencies?

[Peter Otten]

Mark Lawrence wrote:

> On 21/12/2013 01:58, Ned Batchelder wrote:
>>
>> If you have a zero, you can split on it with:
>> bytestring.split(bytes([0])), but that doesn't explain why find can take
>> a simple zero, and split has to take a bytestring with a zero in it.
>>
> 
> Create a bytearray(range(256)) and partition it on 128.  I'd expect to
> see the original effectively cut in half with 128 as the separator.  You
> actually get the original with two empty bytearrays, which makes no
> sense to me at all.

>>> bytearray(b"alpha\x00\x00\x00beta").partition(0)
Traceback (most recent call last):
  File "", line 1, in 
ValueError: empty separator
>>> bytearray(b"alpha\x00\x00\x00beta").partition(1)
(bytearray(b'alpha'), bytearray(b'\x00'), bytearray(b'\x00\x00beta'))
>>> bytearray(b"alpha\x00\x00\x00beta").partition(2)
(bytearray(b'alpha'), bytearray(b'\x00\x00'), bytearray(b'\x00beta'))

suggests that there is an implicit cast to bytearray

>>> bytearray(0)
bytearray(b'')
>>> bytearray(2)
bytearray(b'\x00\x00')

While consistent I don't see how this can ever be the desired behaviour and 
recommend that you file a bug report.
 
> I also looked in test_bytes.py, read as far as "XXX This is a mess" and
> promptly gave up.
 


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: GUI:-please answer want to learn GUI programming in python , how should i proceed.

[Martin Schöön]

Den 2013-12-20 skrev Mark Lawrence :
> On 20/12/2013 17:52, Martin Schöön wrote:
>>
>> Coming from many years of SUN Solaris experience I may be a bit
>> spoiled when it comes to robustness :-)
>>
>
> You never had the pleasure of working on VMS then? :)
>
Only very, very little and I have no clear memories of it. It was
back in the days before I learned to save my work every few seconds
just in case because just in case didn't happen to us then.

I took OS stability for granted in those days.

/Martin
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why Python is like C++

[Tim Chase]

On 2013-12-21 08:43, Tim Chase wrote:
> Then there's the 6502 assembly on that Apple with its 2 user-facing
> registers (plus the Instruction Pointer and Stack Pointer), so I
> guess you could say that it has 1-bit variable names ;-)

Doh, forgot momentarily that the 6502 had X, Y, and A, making THREE
registers.  ooh, the luxury of 2-bit naming conventions! :-D

-tkc



-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why Python is like C++

[Tim Chase]

On 2013-12-21 11:19, Christian Gollwitzer wrote:
> GW-BASIC was a weak language, but two significant characters is 
> definitely too few. I think it was eight. Never used QuickBasic, I
> went Turbo Pascal instead, which had 32 significant characters.

In know that my first BASIC, Applesoft BASIC had the 2-character
names, and you had to load Integer Basic (with Ints in addition to the
standard Floats used in the BASIC provided by the ROM, a strange
choice).  So moving to Turbo Pascal (started with a 3.x series
version, but 6.x was a major upgrade) gave me more breathing-room and
data-types than I know what to do with :-)

Then there's the 6502 assembly on that Apple with its 2 user-facing
registers (plus the Instruction Pointer and Stack Pointer), so I
guess you could say that it has 1-bit variable names ;-)

-tkc


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why Python is like C++

[Roy Smith]

In article ,
 Dan Stromberg  wrote:

> On Fri, Dec 20, 2013 at 9:34 PM, Mark Lawrence  
> wrote:
> > On 20/12/2013 14:19, Roy Smith wrote:
> >>
> >> http://xkcd.com/1306/
> >>
> >
> > I believe that to be a very superficial like.  They're unlike in that once
> > C++ people have compiled their code they can head down to the pub, but
> > Python people have to stay at work testing because the compiler hasn't
> > caught all potential errors.
> 
> Python should be used with static analysis (EG pylint), IMO, for
> reliability.  Python should also be used, IMO, with a good set of
> automated unit, integration and system tests.
> 
> C++ should use automated tests too, but is often used without because
> the compilers make it almost reasonable to do without.  The compilers
> tend to make it so you don't need static analysis, but it's so cheap
> to use static analysis that it's a good idea to do so.

On the last large C++ project I worked on, we decided (i.e. obeyed a 
corporate mandate) to start using Coverity's static analysis tool on our 
15 year old codebase.  I learned a few things about static analysis then.

1) It finds bugs you would never find yourself.

2) If your code does tricky things, you can fool the static analyzer, 
leading to false positives.  Presumably, it also leads to false 
negatives, but you don't know about those :-(

3) If you're going to use static analysis, probably the best way is to 
start using it from day one.  Trying to duct-tape a static analysis step 
into your development process for a legacy codebase is probably more 
effort than it's worth.

4) I suspect static analysis does a lot better on a language like Java 
(which has introspection) than it does on C++.  One of the biggest 
problems is that the preprocessor means the code that compiles is not 
the code that you look at.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why Python is like C++

[Michael Torrie]

On 12/21/2013 01:17 AM, Chris Angelico wrote:
> GW-BASIC is what you're describing. Q-BASIC isn't the same as
> QuickBasic, though. Q-BASIC had subs and functions and stuff, but it
> was still, at its heart, BASIC. And you could DIM something with a
> type, but normally it was the adorning suffix that determined type: A$
> is a string, A% is an integer, A! (or A) is float, A# is double.

Yes you could use suffixes if you wanted to on QuickBasic and QBasic.

QBasic actually was the same language as QuickBasic, just that it was an
interpreter only, not a compiler.  The language itself was identical (to
ver 4.5 if I recall correctly).  If you want a trip down memory lane,
download qb64[1] for your chosen platform and have fun.  qb64 is
actually a full-blown compiler that implements almost all of the
QuickBasic/QBasic language with an integrated IDE that is a
re-implementation of the good old DOS one that was in QBasic and QuickBasic.

[1] http://qb64.net
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why Python is like C++

[Roy Smith]

In article ,
 Tim Chase  wrote:

> In know that my first BASIC, Applesoft BASIC had the 2-character
> names, and you had to load Integer Basic (with Ints in addition to the
> standard Floats used in the BASIC provided by the ROM, a strange
> choice).

Why is it a strange choice?  If you're only going to support a single 
type of numeric value, floats make a lot more sense than ints.  Floats 
are a superset of integers.

Javascript, anyone?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to import Wave files into python?

[diesch111]

On Wednesday, December 18, 2013 8:45:08 AM UTC-8, twilk...@gmail.com wrote:
> How exactly do I import a .wav file and run it?
> 
> also is it possible to run it inside a while loop if so or it just start 
> playing when its run? - Tom 14

Using Pyside/PyQt you can play wave files this way ...
QSound.play(wave_filename)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why Python is like C++

[Tim Chase]

On 2013-12-21 10:59, Roy Smith wrote:
> > In know that my first BASIC, Applesoft BASIC had the 2-character
> > names, and you had to load Integer Basic (with Ints in addition
> > to the standard Floats used in the BASIC provided by the ROM, a
> > strange choice).  
> 
> Why is it a strange choice?  If you're only going to support a
> single type of numeric value, floats make a lot more sense than
> ints.  Floats are a superset of integers.
> 
> Javascript, anyone?

It's one thing when JS uses bajillion-bit precision on the floats.
With an 8-bit processor, the accuracy was wanting (according to
Wikipedia[1], single-precision with 8-bit exponent & 31-bit
significand), so you'd often hit cases where INT1 + INT2 *should*
equal INT3
+ INT4, but because of floating-point errors, they wouldn't.  It's
maddening to have the mathematical equivalent of

  2 + 4 != 1 + 5

manifest itself in your programs.  And even harder to explain to a
middle-schooler that I was at the time. :-/

Also, one of the main reasons to choose INTEGER BASIC on the Apple
was that was notably faster, since FP math was managed in software,
rather than in dedicated FP hardware.

-tkc


[1]
http://en.wikipedia.org/wiki/Applesoft_basic#Background



-- 
https://mail.python.org/mailman/listinfo/python-list

Line based graphic in canvas (vectorgraphic?) scale incorrectly on HDMI monitor.

[jonas . thornvall]

Is there a way to make linebased graphic used in canvas scale correct on any 
monitor?

I run in 1920*1080 on a Philips TV used as monitor does it matter, lines tend 
to get longer vertical then horizontal?

Strange is i really do not see it writing out recangles.







-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Newbie question. Are those different objects ?

[Chris Angelico]

On Sun, Dec 22, 2013 at 3:54 AM, Dennis Lee Bieber
 wrote:
> (heh, the spell-checker suggests that
> "thefullyqualifiednameontheleftafteranysubexpressionshavebeenevaluatedisattachedt"
> should be replaced with "textually")

The spell-checker was scratching its head and going "I'm pretty sure
this isn't right, but I don't know enough of what it says to be sure
it's quite wrong!" and eventually gave up trying to understand you,
and just picked a word kinda like some of the letters and said "Here,
have this as a suggestion, I'm off to the pub. You don't pay me enough
to check words like that.".

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Line based graphic in canvas (vectorgraphic?) scale incorrectly on HDMI monitor.

[Ned Batchelder]

On 12/21/13 1:30 PM, jonas.thornv...@gmail.com wrote:

Is there a way to make linebased graphic used in canvas scale correct on any 
monitor?

I run in 1920*1080 on a Philips TV used as monitor does it matter, lines tend 
to get longer vertical then horizontal?

Strange is i really do not see it writing out recangles.


I'm not sure how we can help without seeing any code.  There's no 
information here that we can use to make a concrete suggestion.


--
Ned Batchelder, http://nedbatchelder.com

--
https://mail.python.org/mailman/listinfo/python-list

Re: Why Python is like C++

[Chris Angelico]

On Sun, Dec 22, 2013 at 2:59 AM, Roy Smith  wrote:
> In article ,
>  Tim Chase  wrote:
>
>> In know that my first BASIC, Applesoft BASIC had the 2-character
>> names, and you had to load Integer Basic (with Ints in addition to the
>> standard Floats used in the BASIC provided by the ROM, a strange
>> choice).
>
> Why is it a strange choice?  If you're only going to support a single
> type of numeric value, floats make a lot more sense than ints.  Floats
> are a superset of integers.

No, reals are a superset of integers, and are also a superset of
floats. Whether a float can precisely represent every int in your pool
depends on their relative sizes; in another thread we've just had
complaints about fixed-size integers in C, but they do simplify
discussions like this!

With IEEE floating point, it's theoretically possible to represent any
integer smaller than 2**M, where M is the size of the mantissa
(including its leading 1 bit). In practical terms, that means your
float has to take up twice as much space as an int would (a 64-bit
float has a 53-bit mantissa, so it can represent 32-bit numbers -
nobody actually asks for 53-bit integer support, but you do have it).
I don't know about non-IEEE float systems, but they'll be doing
something similar.

Arbitrary precision throws a whole new spanner in the works. It's
pretty easy to offer an arbitrary-precision integer type that
guarantees accuracy down to the last digit. Offering a float type that
can represent a ridiculous range of integers is problematic. I notice
that Python offers the former and not the latter :) REXX offered
configurable-precision numeric calculations, but performance dropped
off badly as the precision rose. That is to say, it was fine for the
default 9 digits, fine for 100 digits (but now you have to format
numbers for display, or they'll be ugly), starting to get slow if you
asked for 500 digits, and really quite ridiculously slow with NUMERIC
DIGITS 1.

I wouldn't say that most languages' float type is truly a superset of int.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why Python is like C++

[Gene Heskett]

On Saturday 21 December 2013 13:57:37 Tim Chase did opine:

> On 2013-12-21 08:43, Tim Chase wrote:
> > Then there's the 6502 assembly on that Apple with its 2 user-facing
> > registers (plus the Instruction Pointer and Stack Pointer), so I
> > guess you could say that it has 1-bit variable names ;-)
> 
> Doh, forgot momentarily that the 6502 had X, Y, and A, making THREE
> registers.  ooh, the luxury of 2-bit naming conventions! :-D
> 
> -tkc

And the HD63C09EP kicks them both clear out of the game. Too bad Hitachi is 
to this day, contractually enjoined from even admitting that the new 
registers it sports, or the new, much faster instructions it supports are 
actually in the chip. Like how about a 32 bit value, divided by a 16 bit 
value, 39 clocks worst case?  In a supposedly 8 bit cpu.  Lots of little 
surprises in that 40 pin block of epoxy that was supposed to be a work-a-
like of the Motorola MC6809EP.

Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Be cheerful while you are alive.
-- Phathotep, 24th Century B.C.
A pen in the hand of this president is far more
dangerous than 200 million guns in the hands of
 law-abiding citizens.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Line based graphic in canvas (vectorgraphic?) scale incorrectly on HDMI monitor.

[jonas . thornvall]

Den lördagen den 21:e december 2013 kl. 20:03:17 UTC+1 skrev Ned Batchelder:
> On 12/21/13 1:30 PM, jonas.thornv...@gmail.com wrote:
> 
> > Is there a way to make linebased graphic used in canvas scale correct on 
> > any monitor?
> 
> >
> 
> > I run in 1920*1080 on a Philips TV used as monitor does it matter, lines 
> > tend to get longer vertical then horizontal?
> 
> >
> 
> > Strange is i really do not see it writing out recangles.
> 
> 
> 
> I'm not sure how we can help without seeing any code.  There's no 
> 
> information here that we can use to make a concrete suggestion.
> 
> 
> 
> -- 
> 
> Ned Batchelder, http://nedbatchelder.com
A vertical and horisontal line of same length will be plottet out like this.
There is really no code to show yet, i just write out some lines and noted that 
writing out a verital line of length 400 is longer then a horisontal line of 
same length e.g.

line(100,100,500,100); is shorter
line(300,100,300,500); is longer

__
|
|
|
|
|
|
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Newbie question. Are those different objects ?

[Mark Lawrence]

On 21/12/2013 16:54, Dennis Lee Bieber wrote:

On 21 Dec 2013 12:58:41 GMT, Steven D'Aprano
 declaimed the following:


On Fri, 20 Dec 2013 16:00:22 +, Mark Lawrence wrote:


On 20/12/2013 15:34, rusi wrote:



You are also assuming that the two horizontal lines sometimes called
'equals' have something to do with something called by the same name in
math -- equations



A good point.  Shall I write a PEP asking for a language change which
requires that that stupid = sign is replaced by a keyword reading
something like
thenameonthelefthandsideisassignedtheobjectontherighthandside ?


That's an excellent idea, and I look forward to reading the PEP.


-1 vote... It still has the problematic "assigned" term...

I'd suggest:
thefullyqualifiednameontheleftafteranysubexpressionshavebeenevaluatedisattachedtotheobjectresultingfromevaluationoftheexpressionontheright

(heh, the spell-checker suggests that
"thefullyqualifiednameontheleftafteranysubexpressionshavebeenevaluatedisattachedt"
should be replaced with "textually")



Well you can write the PEP then :)

--
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.


Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: bytearray inconsistencies?

[Mark Lawrence]

On 21/12/2013 13:20, Peter Otten wrote:

Mark Lawrence wrote:


On 21/12/2013 01:58, Ned Batchelder wrote:


If you have a zero, you can split on it with:
bytestring.split(bytes([0])), but that doesn't explain why find can take
a simple zero, and split has to take a bytestring with a zero in it.



Create a bytearray(range(256)) and partition it on 128.  I'd expect to
see the original effectively cut in half with 128 as the separator.  You
actually get the original with two empty bytearrays, which makes no
sense to me at all.



bytearray(b"alpha\x00\x00\x00beta").partition(0)

Traceback (most recent call last):
   File "", line 1, in 
ValueError: empty separator

bytearray(b"alpha\x00\x00\x00beta").partition(1)

(bytearray(b'alpha'), bytearray(b'\x00'), bytearray(b'\x00\x00beta'))

bytearray(b"alpha\x00\x00\x00beta").partition(2)

(bytearray(b'alpha'), bytearray(b'\x00\x00'), bytearray(b'\x00beta'))

suggests that there is an implicit cast to bytearray


bytearray(0)

bytearray(b'')

bytearray(2)

bytearray(b'\x00\x00')

While consistent I don't see how this can ever be the desired behaviour and
recommend that you file a bug report.



http://bugs.python.org/issue20047

--
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.


Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: Line based graphic in canvas (vectorgraphic?) scale incorrectly on HDMI monitor.

[Ned Batchelder]

On 12/21/13 2:12 PM, jonas.thornv...@gmail.com wrote:

Den lördagen den 21:e december 2013 kl. 20:03:17 UTC+1 skrev Ned Batchelder:

On 12/21/13 1:30 PM, jonas.thornv...@gmail.com wrote:


Is there a way to make linebased graphic used in canvas scale correct on any 
monitor?







I run in 1920*1080 on a Philips TV used as monitor does it matter, lines tend 
to get longer vertical then horizontal?







Strange is i really do not see it writing out recangles.




I'm not sure how we can help without seeing any code.  There's no

information here that we can use to make a concrete suggestion.



--

Ned Batchelder, http://nedbatchelder.com

A vertical and horisontal line of same length will be plottet out like this.
There is really no code to show yet, i just write out some lines and noted that 
writing out a verital line of length 400 is longer then a horisontal line of 
same length e.g.

line(100,100,500,100); is shorter
line(300,100,300,500); is longer

__
 |
 |
 |
 |
 |
 |



Sounds like you don't have square pixels.  Either use a monitor which 
does, or adjust your coordinates to take the shape of the pixel into 
account, or try different resolution settings to see if one of them does 
have square pixels.  Also, the settings on the monitor matter also, you 
may be able to adjust them to correct the shape of the pixel.


--
Ned Batchelder, http://nedbatchelder.com

--
https://mail.python.org/mailman/listinfo/python-list

Re: Line based graphic in canvas (vectorgraphic?) scale incorrectly on HDMI monitor.

[jonas . thornvall]

Den lördagen den 21:e december 2013 kl. 20:56:54 UTC+1 skrev Ned Batchelder:
> On 12/21/13 2:12 PM, jonas.thornv...@gmail.com wrote:
> 
> > Den l�rdagen den 21:e december 2013 kl. 20:03:17 UTC+1 skrev Ned 
> > Batchelder:
> 
> >> On 12/21/13 1:30 PM, jonas.thornv...@gmail.com wrote:
> 
> >>
> 
> >>> Is there a way to make linebased graphic used in canvas scale correct on 
> >>> any monitor?
> 
> >>
> 
> >>>
> 
> >>
> 
> >>> I run in 1920*1080 on a Philips TV used as monitor does it matter, lines 
> >>> tend to get longer vertical then horizontal?
> 
> >>
> 
> >>>
> 
> >>
> 
> >>> Strange is i really do not see it writing out recangles.
> 
> >>
> 
> >>
> 
> >>
> 
> >> I'm not sure how we can help without seeing any code.  There's no
> 
> >>
> 
> >> information here that we can use to make a concrete suggestion.
> 
> >>
> 
> >>
> 
> >>
> 
> >> --
> 
> >>
> 
> >> Ned Batchelder, http://nedbatchelder.com
> 
> > A vertical and horisontal line of same length will be plottet out like this.
> 
> > There is really no code to show yet, i just write out some lines and noted 
> > that writing out a verital line of length 400 is longer then a horisontal 
> > line of same length e.g.
> 
> >
> 
> > line(100,100,500,100); is shorter
> 
> > line(300,100,300,500); is longer
> 
> >
> 
> > __
> 
> >  |
> 
> >  |
> 
> >  |
> 
> >  |
> 
> >  |
> 
> >  |
> 
> >
> 
> 
> 
> Sounds like you don't have square pixels.  Either use a monitor which 
> 
> does, or adjust your coordinates to take the shape of the pixel into 
> 
> account, or try different resolution settings to see if one of them does 
> 
> have square pixels.  Also, the settings on the monitor matter also, you 
> 
> may be able to adjust them to correct the shape of the pixel.
> 
> 
> 
> -- 
> 
> Ned Batchelder, http://nedbatchelder.com

It is weird because it seem to be compensated writing out rectangles, but not 
for linegraphics.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Newbie question. Are those different objects ?

[Gene Heskett]

On Saturday 21 December 2013 14:08:02 Chris Angelico did opine:

> On Sun, Dec 22, 2013 at 3:54 AM, Dennis Lee Bieber
> 
>  wrote:
> > (heh, the spell-checker suggests that
> > "thefullyqualifiednameontheleftafteranysubexpressionshavebeenevaluated
> > isattachedt" should be replaced with "textually")
> 
> The spell-checker was scratching its head and going "I'm pretty sure
> this isn't right, but I don't know enough of what it says to be sure
> it's quite wrong!" and eventually gave up trying to understand you,
> and just picked a word kinda like some of the letters and said "Here,
> have this as a suggestion, I'm off to the pub. You don't pay me enough
> to check words like that.".
> 
> ChrisA

Lurking on this list is worth it just for the entertainment value, thanks 
Chris. :)

Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

The heart is wiser than the intellect.
A pen in the hand of this president is far more
dangerous than 200 million guns in the hands of
 law-abiding citizens.
-- 
https://mail.python.org/mailman/listinfo/python-list

Hopper and Backus (was Re: @property simultaneous setter and getter)

[Terry Reedy]

On 12/21/2013 11:59 AM, Dennis Lee Bieber wrote:

On 21 Dec 2013 11:31:22 GMT, Steven D'Aprano



I don't know. What is it? I'm sure your code is the most fabulous,
awesome and brilliant thing since Grace Hopper came up with FORmula
TRANslation back in the 1950s,



As I recall, Grace Hopper was involved in COmmon Business Oriented
Language.


Yes, https://en.wikipedia.org/wiki/Grace_hopper

Somehow, I had the same impression as Steven.

> FORTRAN credit goes to John Backus (the B in BNF notation)

He assembled and directed the team (at IBM, it appears).
https://en.wikipedia.org/wiki/John_Backus

--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

Re: Why Python is like C++

[Terry Reedy]

On 12/21/2013 10:10 AM, Roy Smith wrote:


On the last large C++ project I worked on, we decided (i.e. obeyed a
corporate mandate) to start using Coverity's static analysis tool on our
15 year old codebase.  I learned a few things about static analysis then.


CPython was about that old when Coverity started giving us reports on 
the C part of CPython (about 40 loc). CPython is now essentially 
free of errors detected by Coverity.



1) It finds bugs you would never find yourself.


Coverity apparently found several for CPython.


2) If your code does tricky things, you can fool the static analyzer,
leading to false positives.


One can define code patterns that are false positives, to silence such 
reports.



 Presumably, it also leads to false
negatives, but you don't know about those :-(


We use unit tests to find logic bugs ;-).


3) If you're going to use static analysis, probably the best way is to
start using it from day one.  Trying to duct-tape a static analysis step
into your development process for a legacy codebase is probably more
effort than it's worth.


Some of the C coders on the development team thought it *was* for 
CPython. The fact that CPython has been compiled for, say, 20 different 
systems may have meant that it already depended less on 
'implementation-defined' behavior.


--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

Re: Why Python is like C++

[Roy Smith]

In article ,
 Terry Reedy  wrote:

> On 12/21/2013 10:10 AM, Roy Smith wrote:
> 
> > On the last large C++ project I worked on, we decided (i.e. obeyed a
> > corporate mandate) to start using Coverity's static analysis tool on our
> > 15 year old codebase.  I learned a few things about static analysis then.
> 
> CPython was about that old when Coverity started giving us reports on 
> the C part of CPython (about 40 loc). CPython is now essentially 
> free of errors detected by Coverity.

How many of those errors were real, and how many were "I suppose, 
technically, this isn't quite correct but in real life, it's just never 
going to be an issue?"  I'm not being cynical here; I'm interested to 
know if it really helped.

> > 2) If your code does tricky things, you can fool the static analyzer,
> > leading to false positives.
> 
> One can define code patterns that are false positives, to silence such 
> reports.

Yes, we did some of those.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why Python is like C++

[Gregory Ewing]

Christian Gollwitzer wrote:
GW-BASIC was a weak language, but two significant characters is 
definitely too few. I think it was eight.


That may have been true for MS-DOS era BASICS. If
you have a whopping 640KB for your program, then
it doesn't matter so much.

The 8-bit era was much more constrained. With only
48KB (or less, depending on how fancy a graphics
mode you wanted to use) people didn't like to use
any more chars than they strictly needed!

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: Why Python is like C++

[Gregory Ewing]

Tim Chase wrote:

Doh, forgot momentarily that the 6502 had X, Y, and A, making THREE
registers.  ooh, the luxury of 2-bit naming conventions! :-D


Two bits? That's enough to name FOUR registers!
We've been cheated!

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: Why Python is like C++

[Terry Reedy]

On 12/21/2013 5:28 PM, Roy Smith wrote:

In article ,
  Terry Reedy  wrote:


On 12/21/2013 10:10 AM, Roy Smith wrote:


On the last large C++ project I worked on, we decided (i.e. obeyed a
corporate mandate) to start using Coverity's static analysis tool on our
15 year old codebase.  I learned a few things about static analysis then.


CPython was about that old when Coverity started giving us reports on
the C part of CPython (about 40 loc). CPython is now essentially
free of errors detected by Coverity.


How many of those errors were real, and how many were "I suppose,
technically, this isn't quite correct but in real life, it's just never
going to be an issue?"  I'm not being cynical here; I'm interested to
know if it really helped.


http://search.gmane.org/ search gmane.comp.python.devel for 'Coverity' 
and you should get some relevant hits.



--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

Re: Why Python is like C++

[Gregory Ewing]

Tim Chase wrote:

In know that my first BASIC, Applesoft BASIC had the 2-character
names, and you had to load Integer Basic (with Ints in addition to the
standard Floats used in the BASIC provided by the ROM, a strange
choice).


That's not the way I remember it working. Integer Basic
provided only integers; Applesoft was an alternative ROM
that replaced Integer Basic and provided both float and
int variables.

But I think the only reason to use int variables (ending
with %) in Applesoft was to save memory -- they were
always converted to floats for doing arithmetic. And they
were 16-bit ints, so they had less precision than floats.

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: Why Python is like C++

[Gregory Ewing]

Michael Torrie wrote:

And you could DIM something with a

type, but normally it was the adorning suffix that determined type: A$
is a string, A% is an integer, A! (or A) is float, A# is double.


Some versions of 8-bit Microsoft Basic also had a way of
overriding the default type for a range of names.
So, for example, Fortran programmers could DEFINT I-N
and feel right at home.

I guess that means it would occupy a zero-crossing on
the sigil oscillation curve -- you could have it either
way.

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

fefe

[Downright Trows]

fefwfewfwefwe
-- 
https://mail.python.org/mailman/listinfo/python-list

Pygame vector handling?

[Downright Trows]

I'm trying to pass a vector for the pygame function pygame.transform.rotate The 
only issue is that this doesn't work and I'm in grade 10 and haven't done the 
trig unit yet :L 

Does anyone know a workaround? here is my code if it will help 
http://pastebin.com/FZQB5eux
here is a link to the pygame transform function 
http://www.pygame.org/docs/ref/transform.html
Thank you anyone who is kind enough to attempt to help me.
-- 
https://mail.python.org/mailman/listinfo/python-list

hi

[Downright Trows]

testing
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Pygame vector handling?

[Gary Herron]

On 12/21/2013 08:24 PM, Downright Trows wrote:

I'm trying to pass a vector for the pygame function pygame.transform.rotate The 
only issue is that this doesn't work and I'm in grade 10 and haven't done the 
trig unit yet :L

Does anyone know a workaround? here is my code if it will help 
http://pastebin.com/FZQB5eux
here is a link to the pygame transform function 
http://www.pygame.org/docs/ref/transform.html
Thank you anyone who is kind enough to attempt to help me.


Welcome to programming in  Python!   Please tell us what you want to do, 
what you tried, and how it failed.  Without that information, it's 
impossible to tell what you are asking.


More specifically:

 * The rotate function does not take a vector as an argument so I don't
   know what you mean by "trying to pass a vector for the pygame
   function 
 * "It doesn't work" tells us nothing.  What error message, or what
   incorrect results?
 * I'm not likely to read your hundred+ lines of code trying to find a
   bug.  Please reduce you question to one or several lines of code,
   what you expect them to do, and what they are doing that you
   consider incorrect.

Gary Herron


-- 
https://mail.python.org/mailman/listinfo/python-list