Kevin Modzelewski writes:
> I think in this case, though, if we say for the sake of argument
> that the guaranteed semantics of a dictionary lookup are zero or
I don't understand the point of that argument. It's simply false that
semantics are guaranteed, and all of the dunders might be user
f
Victor Stinner writes:
> 2014-03-18 11:02 GMT+01:00 Atsuo Ishimoto :
> > FYI: Guido was opposed to change error handler of stdin and
> > stdout years ago.
> >
> > http://bugs.python.org/issue2630#msg65493
>
> This issue proposes to use "backslashreplace" error handler for
> stdout. This er
On 19 March 2014 11:09, Steven D'Aprano wrote:
> Although I have tentatively said I think this is okay, it is a change in
> actual semantics of Python code: what you write is no longer what gets
> run. That makes this *very* different from changing the implementation
> of sort -- by analogy, its m
Dear,
I just wrote a sample like this:
testPy/
__init__.py
client.py
SoamFactory.c
SoamFactory.so
soamapi.py
sample/testP.py
export PYTHONPATH=$(TEST_LOCATION):$(TEST_LOCATION)/testPy
Here's the source codes:
__init__.py:
import client
client.
I think in this case, though, if we say for the sake of argument that the
guaranteed semantics of a dictionary lookup are zero or more calls to
__hash__ plus zero or more calls to __eq__, then two back-to-back
dictionary lookups wouldn't have any observable differences from doing only
one, unless y
Dear,
I just wrote a sample like this:
testPy/
__init__.py
client.py
SoamFactory.c
SoamFactory.so
soamapi.py
sample/testP.py
export PYTHONPATH=$(TEST_LOCATION):$(TEST_LOCATION)/testPy
Here's the source codes:
__init__.py:
import client
client.
On 3/18/2014 9:09 PM, Steven D'Aprano wrote:
Currently, the code:
if key in dict:
return dict[key]
performs two dictionary lookups. If you read the code, you can see the
two lookups: "key in dict" performs a lookup, and "dict[key]" performs a
lookup.
The doc says that
@deco
d
On Tue, Mar 18, 2014 at 04:42:29PM -0700, Kevin Modzelewski wrote:
> My 2 cents: it feels like a slippery slope to start guaranteeing the number
> and ordering of calls to comparison functions -- for instance, doing that
> for the sort() function would lock in the sort implementation.
Although I a
My 2 cents: it feels like a slippery slope to start guaranteeing the number
and ordering of calls to comparison functions -- for instance, doing that
for the sort() function would lock in the sort implementation. It feels
like the number/ordering of the calls should be "implementation-defined" in
On Tue, Mar 18, 2014 at 1:47 PM, Terry Reedy wrote:
> The wording is typical for slightly indirect sales pitches in English.
>
yeah, it's spam.
> The same non-specific (no language mentioned) message was sent to
> python-list and, I presume, to tens or even hundreds of other lists (with
> lan
On 19 Mar 2014 07:34, "MRAB" wrote:
> FWIW, I haven't been following the discussion,
Note that this about correctness, not just clarity - using DECREF on member
attributes is not safe, as you may end up exposing a partially destroyed
object to other code.
> but, after a (very)
> quick look, to m
On 2014-03-18 21:06, Nick Coghlan wrote:
On 19 Mar 2014 05:10, "Larry Hastings" mailto:la...@hastings.org>> wrote:
>
> On 03/18/2014 12:05 PM, Georg Brandl wrote:
>>
>> Am 18.03.2014 19:29, schrieb Serhiy Storchaka:
>>>
>>> 26.02.14 11:40, Serhiy Storchaka написав(ла):
Let's ch
26.02.14 11:40, Serhiy Storchaka написав(ла):
Let's choose the least confusing names.
See discussions at:
http://bugs.python.org/issue3081
http://bugs.python.org/issue16447
http://bugs.python.org/issue20440
http://comments.gmane.org/gmane.comp.python.devel/145346
Updated poll results. There
Christian Heimes wrote:
Can the NAO bot do The Silly Walk (tm), too?
From what I gather, making robots do *non*-silly walks
is the hard part.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-de
On 18 March 2014 19:46, Maciej Fijalkowski wrote:
>> A question: how far away will this optimization apply?
>>
>> if x in d:
>> do_this()
>> do_that()
>> do_something_else()
>> spam = d[x]
>
> it depends what those functions do. JIT will inline them and if
> the
On 19 Mar 2014 05:10, "Larry Hastings" wrote:
>
> On 03/18/2014 12:05 PM, Georg Brandl wrote:
>>
>> Am 18.03.2014 19:29, schrieb Serhiy Storchaka:
>>>
>>> 26.02.14 11:40, Serhiy Storchaka написав(ла):
Let's choose the least confusing names.
See discussions at:
http://
On 3/18/2014 12:44 PM, Antoine Pitrou wrote:
Hello Xavier,
It is not obvious your message is appropriate for python-dev. It looks
like mere advertising;
The wording is typical for slightly indirect sales pitches in English.
The same non-specific (no language mentioned) message was sent to
py
On Tue, Mar 18, 2014 at 4:21 PM, Steven D'Aprano wrote:
> On Tue, Mar 18, 2014 at 01:21:05PM +0200, Maciej Fijalkowski wrote:
>
>> note that this is specifically about dicts, where __eq__ will be
>> called undecided number of times anyway (depending on collisions in
>> hash/buckets which is implem
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/18/2014 07:18 AM, Steven D'Aprano wrote:
> Nevertheless, an __eq__ with side-effects is legal Python and may in
> fact be useful.
E.g., for an LRU usecase.
Tres.
- --
===
Tres S
On 03/18/2014 12:05 PM, Georg Brandl wrote:
Am 18.03.2014 19:29, schrieb Serhiy Storchaka:
26.02.14 11:40, Serhiy Storchaka написав(ла):
Let's choose the least confusing names.
See discussions at:
http://bugs.python.org/issue3081
http://bugs.python.org/issue16447
http://bugs.python.org/issue2
Am 18.03.2014 19:29, schrieb Serhiy Storchaka:
> 26.02.14 11:40, Serhiy Storchaka написав(ла):
>> Let's choose the least confusing names.
>>
>> See discussions at:
>>
>> http://bugs.python.org/issue3081
>> http://bugs.python.org/issue16447
>> http://bugs.python.org/issue20440
>> http://comments.gma
On Tue, 18 Mar 2014 19:21:52 +0100
Christian Heimes wrote:
>
> Sounds like a good deal to me. :) Can the NAO bot do The Silly Walk
> (tm), too? I'm even willing to film and upload movies of NAO vs. my
> cats... :)
I've heard it can mend a buildbot with its own hands.
Regards
Antoine.
_
On Mar 18, 2014, at 08:29 PM, Serhiy Storchaka wrote:
>Poll results:
>
>Py_(X)SETREF: +3 (Antoine, Kristján, Nick)
+1
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://m
26.02.14 11:40, Serhiy Storchaka написав(ла):
Let's choose the least confusing names.
See discussions at:
http://bugs.python.org/issue3081
http://bugs.python.org/issue16447
http://bugs.python.org/issue20440
http://comments.gmane.org/gmane.comp.python.devel/145346
Poll results:
Py_(X)SETREF:
On 18.03.2014 17:46, Michael Foord wrote:
>
> On 18/03/14 16:44, Antoine Pitrou wrote:
>>
>> Hello Xavier,
>>
>> It is not obvious your message is appropriate for python-dev. It looks
>> like mere advertising; if it is not, please explain.
>>
>> To clarify what this mailing-list is about: "On this
Le 18/03/2014 04:05, Jeff Allen a écrit :
I found it helpful to practice extensively on something that doesn't
matter. The gap for me is still examples of what I want "done well".
Clearly the Python repos represent complex work, but even accepting it
is all done well, are without much commentary.
On 18/03/14 16:44, Antoine Pitrou wrote:
Hello Xavier,
It is not obvious your message is appropriate for python-dev. It looks
like mere advertising; if it is not, please explain.
To clarify what this mailing-list is about: "On this list the key
Python developers discuss the future of the l
Hello Xavier,
It is not obvious your message is appropriate for python-dev. It looks
like mere advertising; if it is not, please explain.
To clarify what this mailing-list is about: "On this list the key Python
developers discuss the future of the language and its implementation.
Topics inc
Hello,
2014-03-18 18:13 GMT+09:00 Victor Stinner :
> I'm not against backporting the change in Python 3.4.1. It can be seen
> as a bugfix. I don't think that anyone wants a Unicode error when
> reading or printing non-ASCII data from stdin/to stdout. But I would
> like the opinion of other develo
Hi,
We are the manufacturer of the humanoid robot NAO :
http://www.youtube.com/watch?v=nNbj2G3GmAo
We are now offering great opportunities for developers to use NAO and would
like to get in touch with you and your members :
http://www.youtube.com/watch?v=_AxErdP0YI8
Let me know if you may be inte
On Tue, Mar 18, 2014 at 01:21:05PM +0200, Maciej Fijalkowski wrote:
> note that this is specifically about dicts, where __eq__ will be
> called undecided number of times anyway (depending on collisions in
> hash/buckets which is implementation specific to start with)
Exactly. Using a __eq__ metho
On Tue, Mar 18, 2014 at 1:18 PM, Steven D'Aprano wrote:
> On Tue, Mar 18, 2014 at 05:05:56AM -0400, Terry Reedy wrote:
>> On 3/18/2014 3:52 AM, Maciej Fijalkowski wrote:
>> >Hi
>> >
>> >I have a question about calling __eq__ in some cases.
>> >
>> >We're thinking about doing an optimization where
On Tue, Mar 18, 2014 at 05:05:56AM -0400, Terry Reedy wrote:
> On 3/18/2014 3:52 AM, Maciej Fijalkowski wrote:
> >Hi
> >
> >I have a question about calling __eq__ in some cases.
> >
> >We're thinking about doing an optimization where say:
> >
> >if x in d:
> >return d[x]
>
> if d.__contains__(
On Tue, Mar 18, 2014 at 11:35 AM, Nick Coghlan wrote:
> On 18 March 2014 17:52, Maciej Fijalkowski wrote:
>> Hi
>>
>> I have a question about calling __eq__ in some cases.
>>
>> We're thinking about doing an optimization where say:
>>
>> if x in d:
>>return d[x]
>>
>> where d is a dict would
2014-03-18 11:02 GMT+01:00 Atsuo Ishimoto :
> FYI: Guido was opposed to change error handler of stdin and stdout years ago.
>
> http://bugs.python.org/issue2630#msg65493
This issue proposes to use "backslashreplace" error handler for
stdout. This error handler is very different to "surrogateescape
2014-03-18 10:48 GMT+01:00 Nick Coghlan :
> Well, the concern has always been the risk of silently generating bad
> data if there is a mismatch between the OS encoding and the stream
> encodings.
Data can be loaded from OS functions, from files and from stdin. These
3 sources may use various diffe
On 18 March 2014 19:13, Victor Stinner wrote:
> 2014-03-18 9:08 GMT+01:00 Nick Coghlan :
>> On 18 Mar 2014 11:56, "Victor Stinner" wrote:
>>>
>>> Hi,
>>>
>>> I modified Python 3.5 to use the "surrogateescape" error handler (PEP
>>> 383) for stdin and stdout when the LC_CTYPE locale is POSIX ("C"
On 18 March 2014 17:52, Maciej Fijalkowski wrote:
> Hi
>
> I have a question about calling __eq__ in some cases.
>
> We're thinking about doing an optimization where say:
>
> if x in d:
>return d[x]
>
> where d is a dict would result in only one dict lookup (the second one
> being constant fol
2014-03-18 9:08 GMT+01:00 Nick Coghlan :
> On 18 Mar 2014 11:56, "Victor Stinner" wrote:
>>
>> Hi,
>>
>> I modified Python 3.5 to use the "surrogateescape" error handler (PEP
>> 383) for stdin and stdout when the LC_CTYPE locale is POSIX ("C"
>> locale):
>> http://bugs.python.org/issue19977
>
> Ya
On 3/18/2014 3:52 AM, Maciej Fijalkowski wrote:
Hi
I have a question about calling __eq__ in some cases.
We're thinking about doing an optimization where say:
if x in d:
return d[x]
if d.__contains__(x): return d.__getitem__(x)
I do not see any requirement to call x.__eq__ any particula
Am 18.03.2014 09:02, schrieb Victor Stinner:
> 2014-03-18 7:22 GMT+01:00 Georg Brandl :
>> Am 18.03.2014 01:27, schrieb victor.stinner:
>>> http://hg.python.org/cpython/rev/daa6bf71170f
>>> changeset: 89835:daa6bf71170f
>>> user:Victor Stinner
>>> date:Tue Mar 18 00:53:32 2014 +0
On 18 Mar 2014 11:56, "Victor Stinner" wrote:
>
> Hi,
>
> I modified Python 3.5 to use the "surrogateescape" error handler (PEP
> 383) for stdin and stdout when the LC_CTYPE locale is POSIX ("C"
> locale):
> http://bugs.python.org/issue19977
Yay, thanks Victor. I'll let the Fedora folks know this
I have also found hg difficult to get to grips with from cold (but I
like it). The hg command and its help are good, as Antoine says, but if
I'm doing something complex, the visualisation of the change sets that
TortoiseHG provides is invaluable (and of other invisible structures,
such as the M
2014-03-18 7:22 GMT+01:00 Georg Brandl :
> Am 18.03.2014 01:27, schrieb victor.stinner:
>> http://hg.python.org/cpython/rev/daa6bf71170f
>> changeset: 89835:daa6bf71170f
>> user:Victor Stinner
>> date:Tue Mar 18 00:53:32 2014 +0100
>> summary:
>> Add a stub "whatsnew in 3.5" do
Hi,
2014-03-18 7:19 GMT+01:00 Georg Brandl :
> Am 17.03.2014 22:36, schrieb Victor Stinner:
>> I modified the Misc/NEWS file: (...) Is that correct?
>
> The changes not merged in 3.4.0 will all be in 3.5.0; please reinstate the
> NEWS entries under the 3.5 heading.
Oh ok, I didn't notice that 3.4
Hi
I have a question about calling __eq__ in some cases.
We're thinking about doing an optimization where say:
if x in d:
return d[x]
where d is a dict would result in only one dict lookup (the second one
being constant folded away). The question is whether it's ok to do it,
despite the fact
46 matches
Mail list logo
