Hi,
I realised with the issue #3446 that getarg('c') (get a byte) accepts not only
a byte string of 1 byte, but also an unicode string of 1 character (if the
character code is in [0; 255]). I don't think that it's a good idea to accept
unicode here. Example: b"x".center(5, "\xe9") should be a T
Le Tuesday 17 March 2009 13:52:16 Victor Stinner, vous avez écrit :
> I realised with the issue #3446 that getarg('c') (get a byte) accepts not
> only a byte string of 1 byte, but also an unicode string of 1 character (if
> the character code is in [0; 255]). I don't think that it's a good idea to
Steve Holden wrote:
> Why not just put a section in both places that says "can't be bothered
> to spell this out right now" and put a URL in referring to this thread
> on Google ... that appears to have been the traditional approach to
> import semantics :)
Well, first we point to Guido's original
Greg Ewing wrote:
> Um, no -- it says explicitly right at the very top of
> PEP 343 that it's only about factoring out try/finally
> statements.
>
> There's no way that
>
> try:
> code_block
> finally:
> ...
>
> can fail to enter the code block if you get as far as
> the "try". So it
I just noticed that the python-3000 list is still mentioned on
http://www.python.org/community/lists/. I searched around a bit
but it isn't obvious to me where other than here I should report this,
so I'm reporting it here :).
--
R. David Murray http://www.bitdance.com
David> I just noticed that the python-3000 list is still mentioned on
David> http://www.python.org/community/lists/.
Thanks. I passed your note along to the postmaster(s).
Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pytho
On Tue, Mar 17, 2009 at 5:52 AM, Victor Stinner
wrote:
> I realised with the issue #3446 that getarg('c') (get a byte) accepts not only
> a byte string of 1 byte, but also an unicode string of 1 character (if the
> character code is in [0; 255]). I don't think that it's a good idea to accept
> uni
On Tue, Mar 17, 2009 at 06:55, Nick Coghlan wrote:
> Steve Holden wrote:
> > Why not just put a section in both places that says "can't be bothered
> > to spell this out right now" and put a URL in referring to this thread
> > on Google ... that appears to have been the traditional approach to
>
Le Tuesday 17 March 2009 17:27:39, vous avez écrit :
> > The "C" format (get a character) has the opposite problem: it accepts
> > both byte and unicode, whereas byte should be rejected. Example:
> > mmap.write_byte('é') should be a TypeError.
>
> YEah, mmap should be defined exclusively in terms o
On Tue, Mar 17, 2009 at 10:03 AM, Victor Stinner
wrote:
> Le Tuesday 17 March 2009 17:27:39, vous avez écrit :
>> > The "C" format (get a character) has the opposite problem: it accepts
>> > both byte and unicode, whereas byte should be rejected. Example:
>> > mmap.write_byte('é') should be a Type
Does anyone think it was not a good idea to put in-place operations in the operator module? For some objects, they don't map() as
well as their regular counterparts. Some in-place operations rely on the interpreter to take care of the actual assignment. I've
not yet seen good use cases for op
2009/3/17 Raymond Hettinger :
> Does anyone think it was not a good idea to put in-place operations in the
> operator module? For some objects, they don't map() as well as their
> regular counterparts. Some in-place operations rely on the interpreter to
> take care of the actual assignment. I'v
On Tue, Mar 17, 2009 at 2:54 PM, Benjamin Peterson wrote:
> 2009/3/17 Raymond Hettinger :
>> Does anyone think it was not a good idea to put in-place operations in the
>> operator module? For some objects, they don't map() as well as their
>> regular counterparts. Some in-place operations rely o
Right. Since Python doesn't have a notation like "operator +" for
turning operators into functions, the operator module provides this
functionality. Better safe than sorry.
It doesn't really expose this functionality because some of the functionality
is buried in ceval.c and is not exposed by op
Raymond Hettinger rcn.com> writes:
>
> I'm sure that consistency/completeness/safe_vs_sorry
> was the reason they were added. But, if they aren't useful,
> they never should have been (IMO). It wastes the time of
> people who try to use them and then find-out that they don't
> act as expect
> I'm sure that consistency/completeness/safe_vs_sorry was the reason they
> were added. But, if they aren't useful, they never should have been
> (IMO).
Why is that? [you are then giving a reason:]
> It wastes the time of people who try to use them and then
> find-out that they don't act as exp
Maybe someone somewhere has some interesting use for
these in-place operator function. I hope so.
It could be important if you want apply it to mutable objects, i.e.
where the assignment doesn't do anything.
I give up. My original question was whether anyone thought these
were a good idea.
> I give up. My original question was whether anyone thought these
> were a good idea. Look's like the answer is yes,
Correct.
> everyone is happy with
> the functions and are glad they were added in 2.5.
No. I don't really care - I don't use them, nor do I use anything
else of the operator mod
[Martin v. Löwis]
I would object to their removal, though,
because it would hurt my sense of symmetry.
I wasn't going to propose removal. If everyone had
agreed that the operator in-place functions were
problematic, I was going to suggest moving their
docs to a second page and documenting th
Raymond Hettinger wrote:
Does anyone think it was not a good idea to put in-place operations in
the operator module? For some objects, they don't map() as well as
their regular counterparts. Some in-place operations rely on the
interpreter to take care of the actual assignment. I've not yet
20 matches
Mail list logo
