In article <87eingrbh9@benfinney.id.au>,
Ben Finney wrote:
>Lie Ryan writes:
>
>> I generally do not expect operator precedence to be reliable at all
>
>Have another read of the thread. The OP's confusion was not over
>operator precedence, but over how names resolve to values in
>expressions
On Mon, Nov 30, 2009 at 2:05 PM, Lie Ryan wrote:
> On 12/1/2009 5:58 AM, inhahe wrote:
>>
>> i wasn't suggesting it as a feature for python, just pointing out why
>> it might seem counterintuitive.
>
> I'm interested, what do YOU (inhahe) think the result should be? Should both
> become -9 or both
On Sun, Nov 29, 2009 at 5:58 PM, Esmail wrote:
> Brian J Mingus wrote:
>
>>
>>
>>
>> I think you answered your own question. 3**2 comes first in the order of
>> operations, followed by the negation.
>>
>
> No, that's not the problem, I'm ok with the operator precedence of - vs **
>
> My problem i
On 12/1/2009 5:58 AM, inhahe wrote:
i wasn't suggesting it as a feature for python, just pointing out why
it might seem counterintuitive.
I'm interested, what do YOU (inhahe) think the result should be? Should
both become -9 or both become 9. What was your expectation when you
wrote that post
On Mon, Nov 30, 2009 at 1:53 PM, Chris Rebert wrote:
>> On Mon, Nov 30, 2009 at 3:46 AM, Gregory Ewing
>> wrote:
>>> Esmail wrote:
>>>
Wow .. never heard of Concatenative_languages languages before or the
distinction you make. Your distinction explains the behavior, but I
find it s
> On Mon, Nov 30, 2009 at 3:46 AM, Gregory Ewing
> wrote:
>> Esmail wrote:
>>
>>> Wow .. never heard of Concatenative_languages languages before or the
>>> distinction you make. Your distinction explains the behavior, but I
>>> find it somewhat counter-intuitive.
>>
>> You shouldn't find it any mo
Lie Ryan wrote:
On 11/30/2009 12:38 PM, Esmail wrote:
Thanks all!! I get it now :-)
It helped to have a number of different explanations, thanks
for taking the time to post. Much appreciated.
I generally do not expect operator precedence to be reliable at all
except for:
+ - (binary ops, n
one point of confusion could be the use of ** instead of superscript.
it might make things a little bit more counterintuitive-looking than
with superscripts, since the issue with
would only apply to exponents, as
-5*4
and
a = -5
a*4
return the same answer, and superscripts make it a little eas
Esmail wrote:
Wow .. never heard of Concatenative_languages languages before or the
distinction you make. Your distinction explains the behavior, but I
find it somewhat counter-intuitive.
You shouldn't find it any more surprising than the fact that
a = 2 + 3
print a * 5
gives a different
On Sun, Nov 29, 2009 at 8:04 PM, Esmail wrote:
> Chris Rebert wrote:
> Wow .. never heard of Concatenative_languages languages before or the
> distinction you make. Your distinction explains the behavior, but I
> find it somewhat counter-intuitive. (I use the Python interpreter frequently
> for sm
Lie Ryan writes:
> I generally do not expect operator precedence to be reliable at all
Have another read of the thread. The OP's confusion was not over
operator precedence, but over how names resolve to values in
expressions.
--
\ “Life does not cease to be funny when people die any more
On 11/30/2009 12:38 PM, Esmail wrote:
Thanks all!! I get it now :-)
It helped to have a number of different explanations, thanks
for taking the time to post. Much appreciated.
I generally do not expect operator precedence to be reliable at all
except for:
+ - (binary ops, not the unary)
* /
Thanks all!! I get it now :-)
It helped to have a number of different explanations, thanks
for taking the time to post. Much appreciated.
Cheers,
Esmail
--
http://mail.python.org/mailman/listinfo/python-list
Esmail wrote:
> Python 2.6.2 (release26-maint, Apr 19 2009, 01:56:41)
> [GCC 4.3.3] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
>
>
> >>> -3**2
> -9
>
> >>> x = -3
>
> >>> x**2
> 9
> >>>
>
> I would have expected the same result in both cases.
>
> In
* Esmail:
Ok, this is somewhat unexpected:
Python 2.6.2 (release26-maint, Apr 19 2009, 01:56:41)
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> -3**2
-9
>>> x = -3
>>> x**2
9
>>>
I would have expected the same result in both cases.
Init
Esmail writes:
> Brian J Mingus wrote:
> >
> >
> >
> > I think you answered your own question. 3**2 comes first in the
> > order of operations, followed by the negation.
>
> No, that's not the problem, I'm ok with the operator precedence of - vs **
>
> My problem is why I don't get the same resul
It's just like in algebra. You evaluate exponents before the - which, after
all, is just another way to write -1, or times-negative-one. However, a
variable with a negative value is not the same as a value that is being
multiplied by a negative.
-3 ** 2 = (-1)(3)^(2) in algebraic terms. Expon
>> I think you answered your own question. 3**2 comes first in the order
>> of operations, followed by the negation.
>
> No, that's not the problem, I'm ok with the operator precedence of - vs **
>
> My problem is why I don't get the same result if I use the literal -3 or
> a variable that contai
On 29-Nov-09 19:50 PM, Chris Rebert wrote:
On Sun, Nov 29, 2009 at 4:39 PM, Esmail wrote:
Ok, this is somewhat unexpected:
Python 2.6.2 (release26-maint, Apr 19 2009, 01:56:41)
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
-3**2
-9
x = -3
Chris Rebert wrote:
_No_, because using the variable evaluates "-3" as a unit separately
by itself, before the exponentiation ever occurs; it's the same as the
difference between (-3)**2 and -3**2.
Python is not a concatenative programming language[*]; you can't
directly textually replace a vari
Brian J Mingus wrote:
I think you answered your own question. 3**2 comes first in the order of
operations, followed by the negation.
No, that's not the problem, I'm ok with the operator precedence of - vs **
My problem is why I don't get the same result if I use the literal -3 or
a variabl
On Sun, Nov 29, 2009 at 4:39 PM, Esmail wrote:
> Ok, this is somewhat unexpected:
>
> Python 2.6.2 (release26-maint, Apr 19 2009, 01:56:41)
> [GCC 4.3.3] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
>
>
-3**2
> -9
>
x = -3
>
x**2
> 9
>
> I
On Sun, Nov 29, 2009 at 5:39 PM, Esmail wrote:
> Ok, this is somewhat unexpected:
>
> Python 2.6.2 (release26-maint, Apr 19 2009, 01:56:41)
> [GCC 4.3.3] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
>
>
> >>> -3**2
> -9
>
> >>> x = -3
>
> >>> x**2
> 9
> >>>
>
Diez B. Roggisch wrote:
Esmail schrieb:
None of your operations changes a. But I talked about the lists you
bound b and c to before. Those aren't changed as well - they simply are
not pointed to anymore. In your example, that means the will be
garbage-collected, in other scenarios, such as th
Esmail schrieb:
Diez B. Roggisch wrote:
Esmail schrieb:
Could someone help confirm/clarify the semantics of the [:] operator
in Python?
a = range(51,55)
# 1 ##
b = a[:] # b receives a copy of a, but they are independent
>
# The following two are equivalent
###
Dave Angel wrote:
Esmail wrote:
Esmail schrieb:
Could someone help confirm/clarify the semantics of the [:] operator
in Python?
a = range(51,55)
# 1 ##
b = a[:] # b receives a copy of a, but they are independent
Semi-aside, if I wanted to make local copy of a li
Thank you all for your posts - this was very enlightening
and I printed this thread off for future reference.
--
http://mail.python.org/mailman/listinfo/python-list
Dave Angel wrote:
>
>
> Esmail wrote:
>> Diez B.
>> Roggisch wrote:
>>> Esmail schrieb:
Could someone help confirm/clarify the semantics of the [:] operator
in Python?
a = range(51,55)
# 1 ##
b = a[:] # b receives a copy of a, but
Esmail wrote:
Diez B.
Roggisch wrote:
Esmail schrieb:
Could someone help confirm/clarify the semantics of the [:] operator
in Python?
a = range(51,55)
# 1 ##
b = a[:] # b receives a copy of a, but they are independent
>
Semi-aside, if I wanted to make loc
>
> The original list 'a', isn't changed in any of these cases right? And
> modifying b, c or d would not change 'a' either - or am I not understanding
> this correctly?
>
> ## 1 ##
>
> creates a new list and copies all elements from a to b
>
>
Yes.
> ## 2 ##
>
> take an already existing list (em
On Friday 20 November 2009 11:15:55 am Esmail wrote:
> Could someone help confirm/clarify the semantics of the [:] operator
> in Python?
In short, a[:], when "a" is a list, returns a slice ("sublist") of "a" that
happens to contain all the elemnts of "a". In general, a[low:upper:step] will
give
Diez B. Roggisch wrote:
Esmail schrieb:
Could someone help confirm/clarify the semantics of the [:] operator
in Python?
a = range(51,55)
# 1 ##
b = a[:] # b receives a copy of a, but they are independent
>
# The following two are equivalent
# 2
Diez B. Roggisch wrote:
Esmail
schrieb:
Could someone help confirm/clarify the semantics of the [:] operator
in Python?
a = range(51,55)
# 1 ##
b = a[:] # b receives a copy of a, but they are independent
>
# The following two are equivalent
# 2 #
Diez B. Roggisch wrote:
Esmail schrieb:
Could someone help confirm/clarify the semantics of the [:] operator
in Python?
a = range(51,55)
# 1 ##
b = a[:] # b receives a copy of a, but they are independent
>
# The following two are equivalent
# 2 #
Esmail schrieb:
Could someone help confirm/clarify the semantics of the [:] operator
in Python?
a = range(51,55)
# 1 ##
b = a[:] # b receives a copy of a, but they are independent
>
# The following two are equivalent
# 2 ##
c = []
c =
thanks everybody.
--
http://mail.python.org/mailman/listinfo/python-list
On Fri, 22 Aug 2008 00:35:31 -0700 (PDT), akva <[EMAIL PROTECTED]> wrote:
>
> well, frankly I expected a |= b to mean exactly the same as a = a | b
> regardless of the object type.
So did I. I'm glad your post called this to my attention; I
recently told my kid exactly that wrong thing.
--
To
akva wrote:
could you please refer me a link where this is specified? I couldn't
find it in python documentation
http://docs.python.org/ref/augassign.html
"An augmented assignment expression like x += 1 can be rewritten as x =
x + 1 to achieve a similar, but not exactly equal effect. In the
thanks all,
>Yes. That's the exact purpose of the in-place operators when they deal with
>mutable objects. What else did you expect?
well, frankly I expected a |= b to mean exactly the same as a = a | b
regardless of the object type.
> The manual explicitly specifies that mutable objects may imp
akva wrote:
Hi All,
what's the exact semantics of the |= operator in python?
It seems that a |= d is not always equivalent to a = a | d
The manual explicitly specifies that mutable objects may implement the
operation part of operation-assignments by updating in place -- so that
the object
akva wrote:
> Hi All,
>
> what's the exact semantics of the |= operator in python?
> It seems that a |= d is not always equivalent to a = a | d
>
> For example let's consider the following code:
>
> def foo(s):
>s = s | set([10])
>
> def bar(s):
>s |= set([10])
>
> s = set([1,2])
>
>
Paul Miller schrieb:
> In the language documentation, all that is said about thread.error is
> that it's raised "on thread-specific errors." Is there anywhere a
> list of conditions which will cause thread.error to be raised?
I don't think so. However, it is fairly easy to extract such a list
fr
"Evan Klitzke" <[EMAIL PROTECTED]> writes:
>> But the writes are buffered, and close causes the buffer to be
>> flushed. file.close can throw an exception just like fclose, but
>> it will still ensure that the file is closed.
>
> Is this buffering being done by Python or the kernel?
It is done i
"Evan Klitzke" <[EMAIL PROTECTED]> writes:
> Is this buffering being done by Python or the kernel?
I think this refers to buffering done in the C stdio library, which
Python uses.
--
http://mail.python.org/mailman/listinfo/python-list
On 7/17/07, Hrvoje Niksic <[EMAIL PROTECTED]> wrote:
> "Evan Klitzke" <[EMAIL PROTECTED]> writes:
>
> > You should take a look at the man pages for close(2) and write(2) (not
> > fclose). Generally you will only get an error in C if you try to close
> > a file that isn't open. In Python you don't e
Donn Cave <[EMAIL PROTECTED]> wrote:
> I don't think there's any remedy for it, other than the obvious -
> either always flush, or wrap an explicit close in its own exception
> handler.
Even if you have flushed, close() can give an error with some filesystems.
-M-
--
http://mail.python.org/mai
"Evan Klitzke" <[EMAIL PROTECTED]> writes:
> You should take a look at the man pages for close(2) and write(2) (not
> fclose). Generally you will only get an error in C if you try to close
> a file that isn't open. In Python you don't even have to worry about
> that -- if you close a regular file
In article <[EMAIL PROTECTED]>,
"Evan Klitzke" <[EMAIL PROTECTED]> wrote:
...
> > How do I ensure that the close() methods in my finally clause do not
> > throw an exception?
> You should take a look at the man pages for close(2) and write(2) (not
> fclose). Generally you will only get an error
On 7/16/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I'm a Python beginner and I'm trying to open, write and close a file
> in a
> correct manner. I've RTFM, RTFS, and I've read this thread:
> http://groups.google.ca/group/comp.lang.python/browse_thread/thread/73bbda2c920521c/98c73
> How do I ensure that the close() methods in my finally clause do not
> throw an exception?
You have no choice. If close is going to fail, it will fail.
Fortunately you can catch the exception and continue on.
try:
try:
file1.write(somestuff)
finally:
file1.close()
except
On Jul 16, 6:35 pm, [EMAIL PROTECTED] wrote:
> Hello,
>
> I'm a Python beginner and I'm trying to open, write and close a file
> in a
> correct manner. I've RTFM, RTFS, and I've read this
> thread:http://groups.google.ca/group/comp.lang.python/browse_thread/thread/7...
>
> I still cannot figure ou
Sorry for the bad formatting; I've had to post this through the google
groups.
--
http://mail.python.org/mailman/listinfo/python-list
Sorry for not answering such a long time. It's because my question
originated from a discussion within our company which moved out of focus
shortly after I posted, and over waiting for some response from them
before replying here, I forgot about it.
Steve Holden wrote:
>> - f might catch E excep
In article
<[EMAIL PROTECTED]>,
Thomas Lotze <[EMAIL PROTECTED]> wrote:
> Suppose you have a function f which, as part of its protocol, raises some
> standard exception E under certain, well-defined circumstances. Suppose
> further that f calls other functions which may also raise E. How to best
In <[EMAIL PROTECTED]>, Thomas
Lotze wrote:
> I wonder how to solve the following problem the most pythonic way:
>
> Suppose you have a function f which, as part of its protocol, raises some
> standard exception E under certain, well-defined circumstances. Suppose
> further that f calls other fun
Thomas Lotze wrote:
> Hi,
>
> I wonder how to solve the following problem the most pythonic way:
>
> Suppose you have a function f which, as part of its protocol, raises some
> standard exception E under certain, well-defined circumstances. Suppose
> further that f calls other functions which may
In message <[EMAIL PROTECTED]>,
Thomas Lotze wrote:
> Suppose you have a function f which, as part of its protocol, raises some
> standard exception E under certain, well-defined circumstances. Suppose
> further that f calls other functions which may also raise E. How to best
> distinguish whether
57 matches
Mail list logo
