Ben Finney ben+pyt...@benfinney.id.au writes:
James Pye li...@jwp.name writes:
with daemonized():
run_some_subprocess()
This use case is addressed by my up-coming PEP, currently in draft
form but submitted to the PEP editor. A reference implementation is
at
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: bx.center(5, \xe9) should be a
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's not
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
On Tue, Mar 17, 2009 at 5:52 AM, Victor Stinner
victor.stin...@haypocalc.com 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
On Tue, Mar 17, 2009 at 06:55, Nick Coghlan ncogh...@gmail.com 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
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 of bytes.
On Tue, Mar 17, 2009 at 10:03 AM, Victor Stinner
victor.stin...@haypocalc.com 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('é')
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
2009/3/17 Raymond Hettinger pyt...@rcn.com:
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
On Tue, Mar 17, 2009 at 2:54 PM, Benjamin Peterson benja...@python.org wrote:
2009/3/17 Raymond Hettinger pyt...@rcn.com:
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
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
Raymond Hettinger python at 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
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
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
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 module
[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
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
21 matches
Mail list logo
