Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #98777 > unrolled thread

Re: Problems using struct pack/unpack in files, and reading them.

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Problems using struct pack/unpack in files, and reading them. Chris Angelico <rosuav@gmail.com> - 2015-11-14 09:42 +1100
    Re: Problems using struct pack/unpack in files, and reading them. Steven D'Aprano <steve@pearwood.info> - 2015-11-14 13:40 +1100
      Re: Problems using struct pack/unpack in files, and reading them. Chris Angelico <rosuav@gmail.com> - 2015-11-14 14:01 +1100
        Re: Problems using struct pack/unpack in files, and reading them. Steven D'Aprano <steve@pearwood.info> - 2015-11-14 16:40 +1100
          Re: Problems using struct pack/unpack in files, and reading them. Ian Kelly <ian.g.kelly@gmail.com> - 2015-11-14 08:43 -0700
            Re: Problems using struct pack/unpack in files, and reading them. Marko Rauhamaa <marko@pacujo.net> - 2015-11-14 18:52 +0200
              Re: Problems using struct pack/unpack in files, and reading them. Chris Angelico <rosuav@gmail.com> - 2015-11-15 04:04 +1100
                Re: Problems using struct pack/unpack in files, and reading them. Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-11-16 19:19 +1300
              Re: Problems using struct pack/unpack in files, and reading them. Ian Kelly <ian.g.kelly@gmail.com> - 2015-11-14 10:04 -0700
                Re: Problems using struct pack/unpack in files, and reading them. Marko Rauhamaa <marko@pacujo.net> - 2015-11-14 23:53 +0200
                Re: Problems using struct pack/unpack in files, and reading them. Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-11-16 19:15 +1300
                  Re: Problems using struct pack/unpack in files, and reading them. Steven D'Aprano <steve@pearwood.info> - 2015-11-16 23:11 +1100
                    Re: Problems using struct pack/unpack in files, and reading them. Dave Farrance <df@see.replyto.invalid> - 2015-11-17 09:54 +0000
              Re: Problems using struct pack/unpack in files, and reading them. Ian Kelly <ian.g.kelly@gmail.com> - 2015-11-14 10:13 -0700
              Re: Problems using struct pack/unpack in files, and reading them. Random832 <random832@fastmail.com> - 2015-11-14 17:53 -0500
                Re: Problems using struct pack/unpack in files, and reading them. Marko Rauhamaa <marko@pacujo.net> - 2015-11-15 02:12 +0200
                Re: Problems using struct pack/unpack in files, and reading them. Steven D'Aprano <steve@pearwood.info> - 2015-11-15 12:14 +1100
                  Re: Problems using struct pack/unpack in files, and reading them. Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-11-15 11:09 -0500
                    Re: Problems using struct pack/unpack in files, and reading them. Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-11-16 19:11 +1300
              Re: Problems using struct pack/unpack in files, and reading them. MRAB <python@mrabarnett.plus.com> - 2015-11-15 00:49 +0000
            Re: Problems using struct pack/unpack in files, and reading them. Steven D'Aprano <steve@pearwood.info> - 2015-11-15 13:08 +1100
              Re: Problems using struct pack/unpack in files, and reading them. Chris Angelico <rosuav@gmail.com> - 2015-11-15 13:23 +1100
                Re: Problems using struct pack/unpack in files, and reading them. Steven D'Aprano <steve@pearwood.info> - 2015-11-17 00:17 +1100
                  Re: Problems using struct pack/unpack in files, and reading them. Chris Angelico <rosuav@gmail.com> - 2015-11-17 00:27 +1100
          Re: Problems using struct pack/unpack in files, and reading them. Chris Angelico <rosuav@gmail.com> - 2015-11-15 03:59 +1100
      Re: Problems using struct pack/unpack in files, and reading them. Ian Kelly <ian.g.kelly@gmail.com> - 2015-11-13 20:45 -0700
      Re: Problems using struct pack/unpack in files, and reading them. Ian Kelly <ian.g.kelly@gmail.com> - 2015-11-13 20:48 -0700
      Re: Problems using struct pack/unpack in files, and reading them. Chris Angelico <rosuav@gmail.com> - 2015-11-14 14:56 +1100
      Re: Problems using struct pack/unpack in files, and reading them. Chris Angelico <rosuav@gmail.com> - 2015-11-14 14:57 +1100

Page 2 of 2 — ← Prev page 1 [2]

#98840

On Sun, 15 Nov 2015 02:43 am, Ian Kelly wrote:

> On Fri, Nov 13, 2015 at 10:40 PM, Steven D'Aprano <steve@pearwood.info>
> wrote:
>> Python has operator overloading, so it can be anything you want it to be.
>> E.g. you might have a DSL where +feature turns something on and -feature
>> turns it off.
> 
> By that argument we should also have operators ~, !, $, \, ? because
> some hypothetical DSL might someday want to use them for something.

No, I'm not saying that. I'm saying that since Python *already* has unary
plus, it can be overloaded to do anything you want. I'm not saying that
hypothetical DSLs are a good reason to add a bunch of arbitrary new
do-nothing-by-default operators.

(By the way, Python already has the ~ bitwise not operator.)


>> Decimal uses it to force the current precision and rounding, regardless
>> of what the number was initiated to:
>>
>> Counter uses it to strip zero and negative counts:
>>
>> I would expect that symbolic maths software like Sympy probably has use
>> of a unary plus operator, but I'm not sure.
> 
> Unary plus as normalization does not strike me as being very
> intuitive. 

Well, in truth the only truly intuitive interface is the nipple, but using +
for normalisation works for me. It's no more weird than ** for raising to
the power, % for remainder after division, or != for not equal.


>> I might consider stealing an idea from Perl and Javascript, and have
>> unary plus convert strings to a number:
>>
>> +"123"
>> => returns int 123
>> +"1.23"
>> => returns float 1.23
> 
> Eww.

Well of course it's "eww" when you write it as a literal, but you wouldn't
do that except to illustrate the concept, that's just silly. But compare:

number = +raw_input("enter a number: ")

versus:

text = raw_input("enter a number: ")
try:
    number = float(text)
except ValueError: 
    number = int(text)


Or worse, people who don't think of try...except will probably try parsing
the string by hand. 

text = raw_input("enter a number: ").strip()
if text.isdigit() or text.startswith("-") and text[1:].isdigit():
    number = int(text)
else:
    # Floats are allowed a leading - or +, no more than one decimal point,
    # no more than one exponent starting with E or e, and an optional
    # leading + or -  sign in the exponent. Everything else must be digits.
    mantissa, exponent = number.upper().split("E", 1)
    ...

And that's about the point where I stopped because correctly parsing floats
by hand is complicated. But the point is that there was a time in my life
as a Python programmer where I absolutely would have done that, rather than
thinking of try...except.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#98844

On Sun, Nov 15, 2015 at 1:08 PM, Steven D'Aprano <steve@pearwood.info> wrote:
> number = +raw_input("enter a number: ")
>
> versus:
>
> text = raw_input("enter a number: ")
> try:
>     number = float(text)
> except ValueError:
>     number = int(text)

What kinds of strings can float() not handle but int() can, and in a
program that's going to group floats and ints together as "numbers",
will they ever be useful? I'd be more likely to write this as simply:

number = float(input("Enter a number: "))

(Also, I use Python 3. No raw. But same diff.)

ChrisA

[toc] | [prev] | [next] | [standalone]

#98883

On Sun, 15 Nov 2015 01:23 pm, Chris Angelico wrote:

> On Sun, Nov 15, 2015 at 1:08 PM, Steven D'Aprano <steve@pearwood.info>
> wrote:
>> number = +raw_input("enter a number: ")
>>
>> versus:
>>
>> text = raw_input("enter a number: ")
>> try:
>>     number = float(text)
>> except ValueError:
>>     number = int(text)
> 
> What kinds of strings can float() not handle but int() can, 

Heh, I think I got the order of them backwards. You should try to convert to
int first, and if that fails, try float.


> and in a 
> program that's going to group floats and ints together as "numbers",
> will they ever be useful? I'd be more likely to write this as simply:

Obviously this code assumes you want to distinguish between ints and floats
for some reason. In Python, unlike Lua, Javascript and a few others, we do
distinguish between ints and floats. Since they have different
capabilities, that may sometimes be useful:


py> 10.0 ** 400
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: (34, 'Numerical result out of range')
py> 10 ** 400
1000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#98885

On Tue, Nov 17, 2015 at 12:17 AM, Steven D'Aprano <steve@pearwood.info> wrote:
> On Sun, 15 Nov 2015 01:23 pm, Chris Angelico wrote:
>
>> On Sun, Nov 15, 2015 at 1:08 PM, Steven D'Aprano <steve@pearwood.info>
>> wrote:
>>> number = +raw_input("enter a number: ")
>>>
>>> versus:
>>>
>>> text = raw_input("enter a number: ")
>>> try:
>>>     number = float(text)
>>> except ValueError:
>>>     number = int(text)
>>
>> What kinds of strings can float() not handle but int() can,
>
> Heh, I think I got the order of them backwards. You should try to convert to
> int first, and if that fails, try float.

Ah! Yes, that makes sense then. I assumed this...

>> and in a
>> program that's going to group floats and ints together as "numbers",
>> will they ever be useful? I'd be more likely to write this as simply:

... on the basis of the "float first" check.

> Obviously this code assumes you want to distinguish between ints and floats
> for some reason. In Python, unlike Lua, Javascript and a few others, we do
> distinguish between ints and floats. Since they have different
> capabilities, that may sometimes be useful:
>
>
> py> 10.0 ** 400
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> OverflowError: (34, 'Numerical result out of range')
> py> 10 ** 400
> 1000000000000000000000000000000000000000000000000000000000000000000000000
> 0000000000000000000000000000000000000000000000000000000000000000000000000
> 0000000000000000000000000000000000000000000000000000000000000000000000000
> 0000000000000000000000000000000000000000000000000000000000000000000000000
> 0000000000000000000000000000000000000000000000000000000000000000000000000
> 000000000000000000000000000000000000

Right. If you check int() first and then float(), you can make use of
this. But if the user enters that string and you try to float() it, it
will work:

>>> float(str(int(10**400)))
inf

Hence my confusion. :)

With that small change, your code makes fine sense.

ChrisA

[toc] | [prev] | [next] | [standalone]

#98817

On Sun, Nov 15, 2015 at 2:43 AM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
> On Fri, Nov 13, 2015 at 10:40 PM, Steven D'Aprano <steve@pearwood.info> wrote:
>> Python has operator overloading, so it can be anything you want it to be.
>> E.g. you might have a DSL where +feature turns something on and -feature
>> turns it off.
>
> By that argument we should also have operators ~, !, $, \, ? because
> some hypothetical DSL might someday want to use them for something.

Unary tilde does, doing bitwise negation on integers. Backslash
probably never will, due to confusion with line continuation and
stuff. But let's look at the parallel-universe Python in which unary
plus never existed (but unary minus did). The PEP preamble for its
inclusion says:

Abstract
This PEP proposes a new unary version of the binary + operator.

Specification
A new unary operator is added to the Python language:
=======  ========================= ===========
 Op      Precedence/associativity     Method
=======  ========================= ===========
``+``    Same as unary ``-``       ``__pos__``
=======  ========================= ===========

No implementations of this methods is added to the builtin or standard
library types. However, we foresee that Domain-Specific Languages can
make use of this parallel to unary minus; see Intended usage details
below for details.


Okay. I've done my bit, stealing text from PEP 465. Now Steven, you
can write the Motivation section. There's a lot of similarities here
(Python's built-in types do not need @ or unary + for anything), but
the big push for 465 was that there have been calls for the new
operator for years. So... where would the "please add unary plus"
calls come from?

ChrisA

[toc] | [prev] | [next] | [standalone]

#98790

On Nov 13, 2015 8:03 PM, "Chris Angelico" <rosuav@gmail.com> wrote:
>
> On Sat, Nov 14, 2015 at 1:40 PM, Steven D'Aprano <steve@pearwood.info>
wrote:
> > On Sat, 14 Nov 2015 09:42 am, Chris Angelico wrote:
> >
> >> However, this is a reasonable call for the abolition of unary plus...
> >
> > The only way you'll take unary plus out of Python is by prying it from
my
> > cold, dead hands.
> >
> >
> > BTW, unary minus suffers from the same "problem":
> >
> > x =- y  # oops, meant x -= y
> >
> > If anything, this is an argument against the augmented assignment
> > short-cuts, rather than the operators.
>
> Yes, unary minus has the same issue - but it's a lot more important
> than unary plus is. In ECMAScript, unary plus means "force this to be
> a number"; what's its purpose in Python?

It forces a Counter to contain only positive counts?

[toc] | [prev] | [next] | [standalone]

#98791

On Nov 13, 2015 8:03 PM, "Chris Angelico" <rosuav@gmail.com> wrote:
>
> On Sat, Nov 14, 2015 at 1:40 PM, Steven D'Aprano <steve@pearwood.info>
wrote:
> > On Sat, 14 Nov 2015 09:42 am, Chris Angelico wrote:
> >
> >> However, this is a reasonable call for the abolition of unary plus...
> >
> > The only way you'll take unary plus out of Python is by prying it from
my
> > cold, dead hands.
> >
> >
> > BTW, unary minus suffers from the same "problem":
> >
> > x =- y  # oops, meant x -= y
> >
> > If anything, this is an argument against the augmented assignment
> > short-cuts, rather than the operators.
>
> Yes, unary minus has the same issue - but it's a lot more important
> than unary plus is. In ECMAScript, unary plus means "force this to be
> a number"; what's its purpose in Python?

I'm not sure "force this to be a number" is really a justification. Without
it you could just use - - (but be careful not to write that as --) in the
manner of using !! as "force to boolean". Or just call Number().

[toc] | [prev] | [next] | [standalone]

#98792

On Sat, Nov 14, 2015 at 2:45 PM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
>> Yes, unary minus has the same issue - but it's a lot more important
>> than unary plus is. In ECMAScript, unary plus means "force this to be
>> a number"; what's its purpose in Python?
>
> It forces a Counter to contain only positive counts?

Did not know that, and would not have gone looking for it. If Python
hadn't had a unary plus operator, Counter would have managed in some
other way, without being materially impacted by it.

ChrisA

[toc] | [prev] | [next] | [standalone]

#98793

On Sat, Nov 14, 2015 at 2:48 PM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
>> Yes, unary minus has the same issue - but it's a lot more important
>> than unary plus is. In ECMAScript, unary plus means "force this to be
>> a number"; what's its purpose in Python?
>
> I'm not sure "force this to be a number" is really a justification. Without
> it you could just use - - (but be careful not to write that as --) in the
> manner of using !! as "force to boolean". Or just call Number().

I don't use it myself, but I saw something about asm.js that
demonstrated the use of "x = +x;" to mean "x is a number", and "x =
x|0;" to mean "x is an integer".

ChrisA

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.python

csiph-web