On May 19, 2011, at 7:40 PM, Ethan Furman wrote:
> Several folk have said that objects that compare equal must hash equal...
And so do the docs:
http://docs.python.org/dev/reference/datamodel.html#object.__hash__
, "the only required property is that objects which compare equal have the same
2011/5/19 Ethan Furman :
> If anybody has a link to or an explanation why equal values must be equal
> hashes I'm all ears. My apologies in advance if this is an incredibly naive
> question.
https://secure.wikimedia.org/wikipedia/en/wiki/Hash_table
--
Regards,
Benjamin
Nick Coghlan wrote:
On Thu, May 19, 2011 at 6:43 PM, Nick Coghlan wrote:
For point 2, I'm personally +0 on the idea of having 1-element bytes
and bytearray objects delegate hashing and comparison operations to
the corresponding integer object. We have the power to make the
obvious code correct
Python 3.3 is not supposed to create .pyc files in the same directory
than the .py files. So I don't understand the following code.
Le jeudi 19 mai 2011 à 19:56 +0200, tarek.ziade a écrit :
> http://hg.python.org/cpython/rev/9d1fb6a9104b
> changeset: 70207:9d1fb6a9104b
> user:Tarek Ziade
On 5/18/2011 10:19 AM, Nadeem Vawda wrote:
> I'm not sure why you would encounter code like that in the first place.
> Surely any code of the form:
>
> ''.join(c for c in my_string)
>
> would just return my_string? Or am I missing something?
You might more-or-less legitimately encounter it if t
On 5/19/2011 3:49 AM, Nick Coghlan wrote:
It's a mental model problem. People try to think of bytes as
equivalent to 2.x str and that's just wrong, wrong, wrong. It's far
closer to array.array('c').
Or like C char arrays
Strings are basically *unique* in
returning a length 1 instance of them
On 19.05.2011 10:37, Stefan Behnel wrote:
> Xavier Morel, 19.05.2011 09:41:
>> On 2011-05-19, at 07:28 , Georg Brandl wrote:
>>> On 19.05.2011 00:39, Greg Ewing wrote:
If someone sees that
some_var[3] == b'd'
is true, and that
some_var[3] == 100
is a
On 19.05.2011 13:35, Tarek Ziadé wrote:
> Hey
>
> I've pushed packaging in stdlib. There are a few buildbots errors
> we're fixing right now.
>
> We will continue our work in their directly for now on.
Rock on!
Georg
___
Python-Dev mailing list
Pyth
On May 19, 2011, at 1:43 PM, Guido van Rossum wrote:
> -1; the result is not a *character* but an integer.
Well, really the result ought to be an octet, but I suppose adding an 'octet'
type is beyond the scope of even this sprawling discussion :).
> I'm personally favoring using b'a'[0] and po
On Wed, May 18, 2011 at 2:34 PM, Victor Stinner
wrote:
> Le mercredi 18 mai 2011 à 16:19 +0200, Nadeem Vawda a écrit :
>> I'm not sure why you would encounter code like that in the first place.
>
> Well, I found the STORE_FAST/LOAD_FAST "issue" while trying to optimize
> the this module which reim
On Thu, May 19, 2011 at 10:50 AM, Ethan Furman wrote:
> Last thought I have for a possible 'solution' -- when a bytes object is
> tested for equality against an int raise TypeError. Precedent being sum()
> raising a TypeError when passed a list of strings because performance is so
> poor. Reason
On Thu, May 19, 2011 at 1:43 AM, Nick Coghlan wrote:
> OK, summarising the thread so far from my point of view.
>
> 1. There are some aspects of the behavior of bytes() objects that
> tempt people to think of them as string-like objects (primarily the
> b'' literals and their use in repr(), along
Nick Coghlan wrote:
OK, summarising the thread so far from my point of view.
[snip]
To be honest, I don't think there is a lot we can do here except to
further emphasise in the documentation and elsewhere that *bytes is
not a string type* (regardless of any API similarities retained to
ease t
On Thu, May 19, 2011 at 1:35 PM, Tarek Ziadé wrote:
> Hey
>
> I've pushed packaging in stdlib. There are a few buildbots errors
> we're fixing right now.
FYI.
there are still some failures we're fixing. Thanks for your patience
and thanks to the folks that are helping me on this :)
I expect the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/18/2011 10:46 PM, anatoly techtonik wrote:
> On Wed, May 18, 2011 at 10:37 PM, Georg Brandl wrote:
>> On 18.05.2011 21:09, "Martin v. Löwis" wrote:
>>> Am 18.05.2011 20:39, schrieb Hagen Fürstenau:
> On behalf of the Python development team,
Several of the PSF blogs hosted on Google's Blogger platform are experiencing
issues as fallout from the recent maintenance problems they had. We have
already had to recreate at least one of the translations for Python Insider in
order to be able to publish to it, and now we can't edit posts on
Victor Stinner wrote:
I suppose that you have the current value of range(1) on the stack:
DUP_TOP; BINARY_MULTIPLY; gives you the square. You don't need the x
variable (LOAD_FAST/STORE_FAST).
That seems far too special-purpose to be worth it to me.
--
Greg
Hey
I've pushed packaging in stdlib. There are a few buildbots errors
we're fixing right now.
We will continue our work in their directly for now on.
The next "big" commit will be for the documentation,
Cheers
Tarek
--
Tarek Ziadé | http://ziade.org
On 19/05/2011 10:25, Łukasz Langa wrote:
Wiadomość napisana przez Stefan Behnel w dniu 2011-05-19, o godz. 10:37:
But why wouldn't "they" expect `b'de' + 1` to work as well in this case? If a
1-byte bytes is equivalent to an integer, why not an arbitrary one as well?
The result of this must o
On Thu, May 19, 2011 at 6:43 PM, Nick Coghlan wrote:
> For point 2, I'm personally +0 on the idea of having 1-element bytes
> and bytearray objects delegate hashing and comparison operations to
> the corresponding integer object. We have the power to make the
> obvious code correct code, so let's
Le mercredi 18 mai 2011 à 21:44 -0400, Terry Reedy a écrit :
> On 5/18/2011 5:34 PM, Victor Stinner wrote:
>
> You initial example gave me the impression that the issue has something
> to do with join in particular, or even comprehensions in particular. It
> is really about for loops.
>
> >>>
On Thu, 19 May 2011 17:49:47 +1000
Nick Coghlan wrote:
>
> It's a mental model problem. People try to think of bytes as
> equivalent to 2.x str and that's just wrong, wrong, wrong. It's far
> closer to array.array('c'). Strings are basically *unique* in
> returning a length 1 instance of themselv
Le jeudi 19 mai 2011 à 10:47 +1200, Greg Ewing a écrit :
> Victor Stinner wrote:
>
> >squares = (x*x for x in range(1))
>
> What bytecode would you optimise that into?
I suppose that you have the current value of range(1) on the stack:
DUP_TOP; BINARY_MULTIPLY; gives you the square.
On 2011-05-19, at 11:25 , Łukasz Langa wrote:
> Wiadomość napisana przez Stefan Behnel w dniu 2011-05-19, o godz. 10:37:
>
>>> But why wouldn't "they" expect `b'de' + 1` to work as well in this case? If
>>> a 1-byte bytes is equivalent to an integer, why not an arbitrary one as
>>> well?
>>
>>
Łukasz Langa, 19.05.2011 11:25:
Wiadomość napisana przez Stefan Behnel w dniu 2011-05-19, o godz. 10:37:
But why wouldn't "they" expect `b'de' + 1` to work as well in this case? If a
1-byte bytes is equivalent to an integer, why not an arbitrary one as well?
The result of this must obviously
Wiadomość napisana przez Stefan Behnel w dniu 2011-05-19, o godz. 10:37:
>> But why wouldn't "they" expect `b'de' + 1` to work as well in this case? If
>> a 1-byte bytes is equivalent to an integer, why not an arbitrary one as well?
>
> The result of this must obviously be b"de1".
I hope you're
On Thu, May 19, 2011 at 7:34 AM, Victor Stinner
wrote:
> But it is slower whereas I read somewhere than generators are faster
> than loops.
Are you sure it wasn't that generator expressions can be faster than
list comprehensions (if the memory savings are significant)?
Or that a reduction functi
On Thu, May 19, 2011 at 2:51 AM, Éric Araujo wrote:
> Isn’t support.import_module or somesuch useful for this kind of checks?
You have to restructure your tests into the appropriate files for that
to work, as support.import_module() throws SkipTest if the module
isn't available.
Cheers,
Nick.
-
OK, summarising the thread so far from my point of view.
1. There are some aspects of the behavior of bytes() objects that
tempt people to think of them as string-like objects (primarily the
b'' literals and their use in repr(), along with the fact that they
fill roles that were filled by str in i
Xavier Morel, 19.05.2011 09:41:
On 2011-05-19, at 07:28 , Georg Brandl wrote:
On 19.05.2011 00:39, Greg Ewing wrote:
If someone sees that
some_var[3] == b'd'
is true, and that
some_var[3] == 100
is also true, they might expect to be able to do things
like
n = b'd' + 1
and get
On 2011-05-19, at 09:49 , Nick Coghlan wrote:
> On Thu, May 19, 2011 at 5:10 AM, Eric Smith wrote:
>> On 05/18/2011 12:16 PM, Stephen J. Turnbull wrote:
>>> Robert Collins writes:
>>>
>>> > Its probably too late to change, but please don't try to argue that
>>> > its correct: the continued conf
Robert Collins writes:
> Thats separate to the implementation issues I have mentioned in this
> thread and previous.
Oops, sorry.
Nevertheless, I personally think that b'a'[0] == 97 is a good idea,
and consistent with everything else in Python. It's Unicode (str)
that is weird, it's str is su
On Thu, May 19, 2011 at 5:10 AM, Eric Smith wrote:
> On 05/18/2011 12:16 PM, Stephen J. Turnbull wrote:
>> Robert Collins writes:
>>
>> > Its probably too late to change, but please don't try to argue that
>> > its correct: the continued confusion of folk running into this is
>> > evidence that
On 2011-05-19, at 07:28 , Georg Brandl wrote:
> On 19.05.2011 00:39, Greg Ewing wrote:
>> Ethan Furman wrote:
>>
>>> some_var[3] == b'd'
>>>
>>> 1) a check to see if the bytes instance is length 1
>>> 2) a check to see if
>>> i) the other object is an int, and
>>> 2) 0 <= other_obj < 256
>>>
> 3.2.1b1 was already merged back. (And 3.2.1rc1 will also be merged back
> soon, since there will be a 3.2.1rc2.)
Thanks for the clarification! :-)
Cheers,
Hagen
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinf
35 matches
Mail list logo
