On 1 April 2018 at 04:15, Mikhail V wrote:
> MRAB writes:
>
>
>> > UnicodeEncodeError: 'charmap' codec can't encode character
>> >
>> > when it meets a non-ascii char.
>> >
>> > e.g. tried this:
>> > pip search pygame > a.txt
>> >
>> Well, _I_ didn't get an error!
>>
>> One of the lines is:
>>
>>
On 1 April 2018 at 03:16, MRAB wrote:
> On 2018-04-01 02:50, Mikhail V wrote:
>>
>> Steven D'Aprano writes:
>>
PS: was looking forward to PIP improvements on Windows, on 9.0.3 still
some issues. E.g. trying to redirect output from 'pip search ... >
a.txt' gives a wall of errors
On Saturday, March 31, 2018 at 4:30:04 PM UTC+5:30, bartc wrote:
> On 30/03/2018 21:13, C W wrote:
> > Hello all,
> >
> > I want to create a dictionary.
> >
> > The keys are 26 lowercase letters. The values are 26 uppercase letters.
> >
> > The output should look like:
> > {'a': 'A', 'b': 'B',..
On Mon, Apr 2, 2018 at 3:03 AM, Rustom Mody wrote:
> On Saturday, March 31, 2018 at 4:30:04 PM UTC+5:30, bartc wrote:
>> On 30/03/2018 21:13, C W wrote:
>> > Hello all,
>> >
>> > I want to create a dictionary.
>> >
>> > The keys are 26 lowercase letters. The values are 26 uppercase letters.
>> >
>
What would be the most performance efficient way of checking if a bytes is
all zeros? Currently its `key == b'\x00' * len(key)` however, because its
Python 2/3 compatible:
sum(key) == 0 is invalid
key == bytes(len(key)) is invalid
I already considered precomputing the rhs value.
Length of key is
Some interesting timeits:
In [7]: timeit('sum(x)==0', 'x=bytes(10)')
Out[7]: 0.30194770699927176
In [11]: timeit('x==bytes(10)', 'x=bytes(10)')
Out[11]: 0.2181608650007547
In [12]: timeit('x==z*10', 'x=bytes(10); z=bytes(1)')
Out[12]: 0.1092393600010837
In [13]: timeit('x==x2', 'x=bytes(10); z=
On 2018-04-01 11:26, Paul Moore wrote:
On 1 April 2018 at 04:15, Mikhail V wrote:
MRAB writes:
> UnicodeEncodeError: 'charmap' codec can't encode character
>
> when it meets a non-ascii char.
>
> e.g. tried this:
> pip search pygame > a.txt
>
Well, _I_ didn't get an error!
One of the lines
On 2018-04-01 18:55, Arkadiusz Bulski wrote:
What would be the most performance efficient way of checking if a bytes is
all zeros? Currently its `key == b'\x00' * len(key)` however, because its
Python 2/3 compatible:
sum(key) == 0 is invalid
key == bytes(len(key)) is invalid
I already considere
Arkadiusz Bulski wrote:
> What would be the most performance efficient way of checking if a bytes is
> all zeros? Currently its `key == b'\x00' * len(key)` however, because its
> Python 2/3 compatible:
>
> sum(key) == 0 is invalid
> key == bytes(len(key)) is invalid
>
> I already considered prec
On 01/04/2018 18:55, Arkadiusz Bulski wrote:
What would be the most performance efficient way of checking if a bytes is
all zeros? Currently its `key == b'\x00' * len(key)` however, because its
Python 2/3 compatible:
That doesn't too efficient, if you first have to construct a compatible
objec
2018-04-01 20:55 GMT+03:00 Arkadiusz Bulski :
> What would be the most performance efficient way of checking if a bytes is
> all zeros?
Try `not any(key)` ;)
With kind regards,
-gdg
--
https://mail.python.org/mailman/listinfo/python-list
Thanks,
timeit gives `not any(key)` same performance as `sum(key)==0`.
niedz., 1 kwi 2018 o 21:03 użytkownik Kirill Balunov <
[email protected]> napisał:
> 2018-04-01 20:55 GMT+03:00 Arkadiusz Bulski :
>
>> What would be the most performance efficient way of checking if a bytes is
>> all z
2018-04-01 22:03 GMT+03:00 Kirill Balunov :
>
>
> 2018-04-01 20:55 GMT+03:00 Arkadiusz Bulski :
>
>> What would be the most performance efficient way of checking if a bytes is
>> all zeros?
>
>
> Try `not any(key)` ;)
>
>
Sorry, I don't timed it before I posted. In reality, it is far from the
fast
On Mon, Apr 2, 2018 at 5:14 AM, Arkadiusz Bulski wrote:
> Thanks,
> timeit gives `not any(key)` same performance as `sum(key)==0`.
Are you timing these on ten-byte keys, or really large keys? For short
keys, just use whatever looks most elegant, and don't worry about
performance. If the key is ac
Arkadiusz Bulski wrote:
> Thanks,
> timeit gives `not any(key)` same performance as `sum(key)==0`.
Then you did not feed it the "right" data
$ python3 -m timeit -s 'key = b"x" + bytes(10**6)' 'sum(key)'
100 loops, best of 3: 15.7 msec per loop
$ python3 -m timeit -s 'key = b"x" + bytes(10**6)' '
My understanding is that the Python interpreter already has enough information
when bytecode-compiling a .py file to determine which names correspond to local
variables in functions. That suggests it has enough information to identify all
valid names in a .py file and in particular to identify w
On Mon, Apr 2, 2018 at 7:24 AM, David Foster wrote:
> My understanding is that the Python interpreter already has enough
> information when bytecode-compiling a .py file to determine which names
> correspond to local variables in functions. That suggests it has enough
> information to identify
> But if it is cheap to detect a wide variety of name errors at compile time,
> is there any particular reason it is not done?
>From my perspective, it is done, but by tools that give better output
than Python's parser. :)
Linters (like pylint) are better than syntax errors here, because they
co
On Sun, Apr 1, 2018 at 2:38 PM, Chris Angelico wrote:
> On Mon, Apr 2, 2018 at 7:24 AM, David Foster wrote:
>> My understanding is that the Python interpreter already has enough
>> information when bytecode-compiling a .py file to determine which names
>> correspond to local variables in functi
On Mon, Apr 2, 2018 at 8:05 AM, Devin Jeanpierre wrote:
> On Sun, Apr 1, 2018 at 2:38 PM, Chris Angelico wrote:
>> On Mon, Apr 2, 2018 at 7:24 AM, David Foster wrote:
>>> My understanding is that the Python interpreter already has enough
>>> information when bytecode-compiling a .py file to det
David Foster writes:
> My understanding is that the Python interpreter already has enough
> information when bytecode-compiling a .py file to determine which
> names correspond to local variables in functions. That suggests it has
> enough information to identify all valid names in a .py file and
Thank you all for the response.
What if I have myDict = {'a': 'B', 'b': 'C',...,'z':'A' }? So now, the
values are shift by one position.
key:abcdefghijklmnopqrstuvwxyz
value: BCDEFGHIJKLMNOPQRSTUVWXYZA
Can I fill in a key and its corresponding value simultaneously on the fly?
Something in t
On Sun, 01 Apr 2018 19:14:05 +, Arkadiusz Bulski wrote:
> Thanks,
> timeit gives `not any(key)` same performance as `sum(key)==0`.
Have you considered what happens when the key is *not* all zeroes?
key = b'\x11'*100
any(key) bails out on the first byte. sum(key) has to add a million
v
A different but related question:
myDict = dict(zip(string.ascii_lowercase + string.ascii_uppercase,
string.ascii_lowercase + string.ascii_uppercase))
>myDict
{'A': 'A', 'B': 'B', 'C': 'C',...,'w': 'w', 'x': 'x', 'y': 'y', 'z': 'z'}
Why are the keys sorted from upper case to lower case? I asked f
On Mon, Apr 2, 2018 at 11:34 AM, C W wrote:
> A different but related question:
>
> myDict = dict(zip(string.ascii_lowercase + string.ascii_uppercase,
> string.ascii_lowercase + string.ascii_uppercase))
>>myDict
> {'A': 'A', 'B': 'B', 'C': 'C',...,'w': 'w', 'x': 'x', 'y': 'y', 'z': 'z'}
>
> Why ar
I am using Python 3.6. I ran the those lines and got a sorted dictionary by
keys.
On Sun, Apr 1, 2018 at 9:38 PM, Chris Angelico wrote:
> On Mon, Apr 2, 2018 at 11:34 AM, C W wrote:
> > A different but related question:
> >
> > myDict = dict(zip(string.ascii_lowercase + string.ascii_uppercase,
On Sun, 01 Apr 2018 14:24:38 -0700, David Foster wrote:
> My understanding is that the Python interpreter already has enough
> information when bytecode-compiling a .py file to determine which names
> correspond to local variables in functions. That suggests it has enough
> information to identify
On Sun, 01 Apr 2018 20:52:35 -0400, C W wrote:
> Thank you all for the response.
>
> What if I have myDict = {'a': 'B', 'b': 'C',...,'z':'A' }? So now, the
> values are shift by one position.
>
> key:abcdefghijklmnopqrstuvwxyz
> value: BCDEFGHIJKLMNOPQRSTUVWXYZA
>
> Can I fill in a key and
Thank you Steven. I am frustrated that I can't enumerate a dictionary by
position index.
Maybe I want to shift by 2 positions, 5 positions...
I want to know/learn how to manipulate dictionary with loop and by its
position location.
On Sun, Apr 1, 2018 at 10:02 PM, Steven D'Aprano <
steve+comp.
On Sun, 01 Apr 2018 22:24:31 -0400, C W wrote:
> Thank you Steven. I am frustrated that I can't enumerate a dictionary by
> position index.
Why do you care about position index?
> Maybe I want to shift by 2 positions, 5 positions...
Sounds like you are trying to program the Caesar Shift cipher,
Yes, you see right through me!
I was able to conquer it, there's probably better ways:
self.myDict = dict(zip(string.ascii_lowercase + string.ascii_uppercase,
string.ascii_lowercase[shift:26] + string.ascii_lowercase[:shift] +
string.ascii_uppercase[shift:26] + string.ascii_uppercase[:shift]))
Ho
On 02/04/18 03:24, C W wrote:
Thank you Steven. I am frustrated that I can't enumerate a dictionary by
position index.
Maybe I want to shift by 2 positions, 5 positions...
I want to know/learn how to manipulate dictionary with loop and by its
position location.
Frankly I think you'd be much
On 4/1/2018 5:24 PM, David Foster wrote:
My understanding is that the Python interpreter already has enough information
when bytecode-compiling a .py file to determine which names correspond to local
variables in functions. That suggests it has enough information to identify all
valid names in
El miércoles, 28 de agosto de 2013, 21:18:26 (UTC-3), Mohsen Pahlevanzadeh
escribió:
> Dear all,
>
> I'm C++ programmer and unfortunately put semicolon at end of my
> statements in python.
>
> Quesion:
> What's really defferences between putting semicolon and don't put?
>
> Yours,
> Mohsen
We
On Sat, Mar 31, 2018 at 7:44 PM, Demian Brecht wrote:
> I might be entirely off my face, but figured I'd ask anyways given I
> haven't figured out a clean solution to this problem myself yet:
>
> I'm trying to write a REST API client that supports both async and
> synchronous HTTP transports (init
35 matches
Mail list logo
