Re: Beta release of pip version 10
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:
>>
>> kundalini (0.4)- LրVE-like PyGame API
>>
>> So it's down to what system encoding (active code page) is in use.
>
> Dunno, it gives me error regardless of active codepage,
> my default is 866, i've set to 1252 or 65001, same error.
>
> The output itself is fine - I see correct glyphs, so the error
> only appears when I redirect to file.
> if I try some python script e.g. "a.py":
> print ("абв")
>
> and run:
> py a.py > a.txt
>
> I get some gibberish in the file.
> So it is probably a global issue. Nothing works in this life :)
That actually sounds more like a redirection issue. Redirecting in the
cmd shell uses the OEM codepage, I believe, and Python outputs to a
pipe using the ANSI codepage, IIRC (I'd have to check to be certain).
Paul
--
https://mail.python.org/mailman/listinfo/python-list
Re: Beta release of pip version 10
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. it's on Windows 10. >>> >>> >>> >>> >>> Don't be shy, tell us what those errors are. >> >> >> >> You meant - don't be lazy to figure out how to reproduce it. >> >> 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: > > kundalini (0.4)- LրVE-like PyGame API > > So it's down to what system encoding (active code page) is in use. As noted in the announcement, please feel free to report the issue. We fixed a lot of encoding errors for pip 10, but it's quite possible that we missed this as no-one reported it. We'll need clear instructions on how to reproduce it, as it doesn't fail for me (Windows 10, pip 10.0.0b1, Python 3.6, Powershell shell): >py -m pip search kundalini kundalini (0.4) - LÖVE-like PyGame API Paul -- https://mail.python.org/mailman/listinfo/python-list
Re: How to fill in a dictionary with key and value from a string?
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',...,'z':'Z' }
>
> > I know I can use string.ascii_lowercase and string.ascii_uppercase, but how
> > do I use it exactly?
> > I have tried the following to create the keys:
> > myDict = {}
> > for e in string.ascii_lowercase:
> > myDict[e]=0
>
> If the input string S is "cat" and the desired output is {'c':'C',
> 'a':'A', 't':'T'}, then the loop might look like this:
>
> D = {}
> for c in S:
> D[c] = c.upper()
>
> print (D)
>
> Output:
>
> {'c': 'C', 'a': 'A', 't': 'T'}
As does…
>>> {c: c.upper() for c in s}
{'a': 'A', 'c': 'C', 't': 'T'} : dict
[Recent pythons; not sure when dict-comprehensions appeared]
--
https://mail.python.org/mailman/listinfo/python-list
Re: How to fill in a dictionary with key and value from a string?
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.
>> >
>> > The output should look like:
>> > {'a': 'A', 'b': 'B',...,'z':'Z' }
>>
>> > I know I can use string.ascii_lowercase and string.ascii_uppercase, but how
>> > do I use it exactly?
>> > I have tried the following to create the keys:
>> > myDict = {}
>> > for e in string.ascii_lowercase:
>> > myDict[e]=0
>>
>> If the input string S is "cat" and the desired output is {'c':'C',
>> 'a':'A', 't':'T'}, then the loop might look like this:
>>
>> D = {}
>> for c in S:
>> D[c] = c.upper()
>>
>> print (D)
>>
>> Output:
>>
>> {'c': 'C', 'a': 'A', 't': 'T'}
>
> As does…
{c: c.upper() for c in s}
> {'a': 'A', 'c': 'C', 't': 'T'} : dict
>
> [Recent pythons; not sure when dict-comprehensions appeared]
3.0, and also backported to 2.7. So go ahead and use 'em.
https://www.python.org/dev/peps/pep-0274/
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
check if bytes is all nulls
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 unknown, could be few bytes, could be megabytes. -- ~ Arkadiusz Bulski -- https://mail.python.org/mailman/listinfo/python-list
Re: check if bytes is all nulls
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=bytes(1); x2=bytes(10)')
Out[13]: 0.05795672599924728
niedz., 1 kwi 2018 o 19:55 użytkownik Arkadiusz Bulski <
[email protected]> napisał:
> 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 unknown, could be few bytes, could be megabytes.
>
> --
> ~ Arkadiusz Bulski
>
--
~ Arkadiusz Bulski
--
https://mail.python.org/mailman/listinfo/python-list
Re: Beta release of pip version 10
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 is:
kundalini (0.4)- LրVE-like PyGame API
So it's down to what system encoding (active code page) is in use.
Dunno, it gives me error regardless of active codepage,
my default is 866, i've set to 1252 or 65001, same error.
The output itself is fine - I see correct glyphs, so the error
only appears when I redirect to file.
if I try some python script e.g. "a.py":
print ("абв")
and run:
py a.py > a.txt
I get some gibberish in the file.
So it is probably a global issue. Nothing works in this life :)
That actually sounds more like a redirection issue. Redirecting in the
cmd shell uses the OEM codepage, I believe, and Python outputs to a
pipe using the ANSI codepage, IIRC (I'd have to check to be certain).
Yep, it's fine until redirected.
--
https://mail.python.org/mailman/listinfo/python-list
Re: check if bytes is all nulls
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 considered precomputing the rhs value. Length of key is unknown, could be few bytes, could be megabytes. Have you tried: not key.lstrip(b'\x00') ? (Although the result of the lstrip could be as long as the original.) Or: set(key) == set(b'\x00') ? (The set will never have more than 256 members.) -- https://mail.python.org/mailman/listinfo/python-list
Re: check if bytes is all nulls
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 precomputing the rhs value. > Length of key is unknown, could be few bytes, could be megabytes. Things you might try: data = ... bytes ... (1) not data.strip(b"\x00") Worst case: creates another len(data)-1 byte string (2) # preparation search = re.compile(b"[^\0x00]").search # actual check search(data) is not None -- https://mail.python.org/mailman/listinfo/python-list
Re: check if bytes is all nulls
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 object of all zeros. sum(key) == 0 is invalid key == bytes(len(key)) is invalid I already considered precomputing the rhs value. Length of key is unknown, (So how can you precompute the table?) could be few bytes, could be megabytes. How likely would be a block of all zeros? Or one that is all zeros but with a sparse smattering of non-zeros? If not very, then just check the bytes one by one. If non-zero, you will know as soon as you see the first non-zero byte, possibly the first one. def allzeros(a): for x in a: if x: return 0 return 1 -- bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: check if bytes is all nulls
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
Re: check if bytes is all nulls
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 zeros? > > > Try `not any(key)` ;) > > With kind regards, > -gdg > -- ~ Arkadiusz Bulski -- https://mail.python.org/mailman/listinfo/python-list
Re: check if bytes is all nulls
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 fastest, it is 10 times slower than `==`, but I like it:) With kind regards, -gdg -- https://mail.python.org/mailman/listinfo/python-list
Re: check if bytes is all nulls
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 actually megabytes long (which seems unlikely, but you did mention it), do your timing tests on megabyte-long keys. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: check if bytes is all nulls
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)' 'not any(key)' 1000 loops, best of 3: 0.168 usec per loop While sum() always has to touch every byte any() can stop at the first non- nul byte. > 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 zeros? >> >> >> Try `not any(key)` ;) -- https://mail.python.org/mailman/listinfo/python-list
Why is the use of an undefined name not a syntax error?
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 which names are not valid. If broken name references were detected at compile time, it would eliminate a huge class of errors before running the program: missing imports, call of misspelled top-level function, reference to misspelled local variable. Of course running a full typechecker like mypy would eliminate more errors like misspelled method calls, type mismatch errors, etc. 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? - David P.S. Here are some uncommon language features that interfere with identifying all valid names. In their absence, one might expect an invalid name to be a syntax error: * import * * manipulating locals() or globals() * manipulating a frame object * eval -- https://mail.python.org/mailman/listinfo/python-list
Re: Why is the use of an undefined name not a syntax error?
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 all valid names in a .py file and in particular to
> identify which names are not valid.
>
It's not as simple as you think. Here's a demo. Using all of the
information available to the compiler, tell me which of these names
are valid and which are not:
import sys
def search_file(fn):
with open(fn) as f:
for line in f:
if "spam" in line and len(line) < 80:
print("Mmmm delicious spam")
if __name__ == "__main__":
try:
search_file(sys.argv[1])
except IndexError:
print("Please provide a file name", file=sys.stderr)
except FileNotFoundError:
print("File not found", file=sys.stderr)
except OSError as Exception:
print("Error %d reading file: %s" %
(Exception.errno, Exception.strerror))
except Exception:
print("Something else went wrong:")
import traceback
traceback.print_exc()
finally:
print("Goodbye.")
Okay. Reckon you got them all? Look again there's probably at least
one sneaky one that you missed. List them for me, and tell me what's
valid and what's not.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Why is the use of an undefined name not a syntax error?
> 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 collect all of the undefined variables, not just the first one. Maybe Python could/should be changed to give more detailed errors of this kind as well. e.g. Clang parse errors for C and C++ are much more thorough and will report all of your typos, not just the first one. > P.S. Here are some uncommon language features that interfere with identifying > all valid names. In their absence, one might expect an invalid name to be a > syntax error: Also, if statements, depending on what you mean by "invalid": def foo(x): if x: y = 3 return y # will raise UnboundLocalError if not x -- Devin -- https://mail.python.org/mailman/listinfo/python-list
Re: Why is the use of an undefined name not a syntax error?
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 functions. That suggests it has enough >> information to identify all valid names in a .py file and in particular to >> identify which names are not valid. >> > > It's not as simple as you think. Here's a demo. Using all of the > information available to the compiler, tell me which of these names > are valid and which are not: This feels like browbeating to me. Just because a programmer finds it hard to figure out manually, doesn't mean a computer can't do it automatically. And anyway, isn't the complexity of reviewing such code an argument in favor of automatic detection, rather than against? For example, whether or not "except Exception:" raises an error depends on what kind of scope we are in and what variable declarations exist in this scope (in a global or class scope, all lookups are dynamic and go up to the builtins, whereas in a function body this would have resulted in an unbound local exception because it uses fast local lookup). What a complex thing. But easy for a computer to detect, actually -- it's right in the syntax tree (and bytecode) what kind of lookup it is, and what paths lead to defining it, and a fairly trivial control flow analysis would discover if it will always, never, or sometimes raise a NameError -- in the absence of "extreme dynamism" like mutating the builtins and so on. :( Unfortunately, the extreme dynamism can't really be eliminated as a possibility, and there's no rule that says "just because this will always raise an exception, we can fail at compile-time instead". Maybe a particular UnboundLocalError was on purpose, after all. Python doesn't know. So probably this can't ever sensibly be a compile error, even if it's a fantastically useful lint warning. -- Devin -- https://mail.python.org/mailman/listinfo/python-list
Re: Why is the use of an undefined name not a syntax error?
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 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 which names are not valid. >>> >> >> It's not as simple as you think. Here's a demo. Using all of the >> information available to the compiler, tell me which of these names >> are valid and which are not: > > This feels like browbeating to me. Just because a programmer finds it > hard to figure out manually, doesn't mean a computer can't do it > automatically. And anyway, isn't the complexity of reviewing such code > an argument in favor of automatic detection, rather than against? Nope, I'm pointing out that it's basically impossible. How can you know at compile time which names are going to be accessible via builtins? It can change. Now, you might say "assume the default set of builtins", and that's fine for a linter; but if you raise a compile-time SyntaxError for it, you'll break perfectly valid code. > For example, whether or not "except Exception:" raises an error > depends on what kind of scope we are in and what variable declarations > exist in this scope (in a global or class scope, all lookups are > dynamic and go up to the builtins, whereas in a function body this > would have resulted in an unbound local exception because it uses fast > local lookup). What a complex thing. But easy for a computer to > detect, actually -- it's right in the syntax tree (and bytecode) what > kind of lookup it is, and what paths lead to defining it, and a fairly > trivial control flow analysis would discover if it will always, never, > or sometimes raise a NameError -- in the absence of "extreme dynamism" > like mutating the builtins and so on. :( > > Unfortunately, the extreme dynamism can't really be eliminated as a > possibility, and there's no rule that says "just because this will > always raise an exception, we can fail at compile-time instead". Maybe > a particular UnboundLocalError was on purpose, after all. Python > doesn't know. So probably this can't ever sensibly be a compile > error, even if it's a fantastically useful lint warning. Yep, exactly. There is no way that you can codify this into an *error*. The set of builtins can change at run-time, and even if you don't actually mutate builtins directly, they can certainly be added and removed between Python versions. And *because* they can change between versions, it's perfectly plausible to have version compatibility shims injected when you're running on an older version. The job of statically recognizing misspelled variable names is best done by a linter, not the language compiler. A linter can do more than the compiler itself can, including checking the file system and saying "probable missed import" if it finds that the name corresponds to a module, or noticing "unused local variable" and "unrecognized global" and suggesting that one of them is misspelled. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Why is the use of an undefined name not a syntax error?
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 in
> particular to identify which names are not valid.
>
> If broken name references were detected at compile time, it would
> eliminate a huge class of errors before running the program: missing
> imports, call of misspelled top-level function, reference to
> misspelled local variable.
I'm not sure what you mean by "valid name" and "broken name references".
The usual error is about unbound names, and binding happens at run-time.
Consider this rather contrived example:
def g(a):
if f1(a):
x = a
else:
y = 2*a
return x+1 if f2(a) else y+1
('a' is there only to prevent some obvious optimisations.)
Are there any broken name references here? You might get an
UnboundLocalError, though that depends on what f1 and f2 return.
--
Ben.
--
https://mail.python.org/mailman/listinfo/python-list
Re: How to fill in a dictionary with key and value from a string?
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 the following structure.
myDict = {}
for i in range(26):
myDict[lowercase] = uppercase
Thank you!
On Sun, Apr 1, 2018 at 1:13 PM, Chris Angelico wrote:
> 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.
> >> >
> >> > The output should look like:
> >> > {'a': 'A', 'b': 'B',...,'z':'Z' }
> >>
> >> > I know I can use string.ascii_lowercase and string.ascii_uppercase,
> but how
> >> > do I use it exactly?
> >> > I have tried the following to create the keys:
> >> > myDict = {}
> >> > for e in string.ascii_lowercase:
> >> > myDict[e]=0
> >>
> >> If the input string S is "cat" and the desired output is {'c':'C',
> >> 'a':'A', 't':'T'}, then the loop might look like this:
> >>
> >> D = {}
> >> for c in S:
> >> D[c] = c.upper()
> >>
> >> print (D)
> >>
> >> Output:
> >>
> >> {'c': 'C', 'a': 'A', 't': 'T'}
> >
> > As does…
> {c: c.upper() for c in s}
> > {'a': 'A', 'c': 'C', 't': 'T'} : dict
> >
> > [Recent pythons; not sure when dict-comprehensions appeared]
>
> 3.0, and also backported to 2.7. So go ahead and use 'em.
>
> https://www.python.org/dev/peps/pep-0274/
>
> ChrisA
> --
> https://mail.python.org/mailman/listinfo/python-list
>
--
https://mail.python.org/mailman/listinfo/python-list
Re: check if bytes is all nulls
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 values. -- Steve -- https://mail.python.org/mailman/listinfo/python-list
Re: How to fill in a dictionary with key and value from a string?
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 for lower
case first, then upper case.
On Sun, Apr 1, 2018 at 8:52 PM, 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 its corresponding value simultaneously on the fly?
>
> Something in the following structure.
>
> myDict = {}
> for i in range(26):
>myDict[lowercase] = uppercase
>
> Thank you!
>
> On Sun, Apr 1, 2018 at 1:13 PM, Chris Angelico wrote:
>
>> 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.
>> >> >
>> >> > The output should look like:
>> >> > {'a': 'A', 'b': 'B',...,'z':'Z' }
>> >>
>> >> > I know I can use string.ascii_lowercase and string.ascii_uppercase,
>> but how
>> >> > do I use it exactly?
>> >> > I have tried the following to create the keys:
>> >> > myDict = {}
>> >> > for e in string.ascii_lowercase:
>> >> > myDict[e]=0
>> >>
>> >> If the input string S is "cat" and the desired output is {'c':'C',
>> >> 'a':'A', 't':'T'}, then the loop might look like this:
>> >>
>> >> D = {}
>> >> for c in S:
>> >> D[c] = c.upper()
>> >>
>> >> print (D)
>> >>
>> >> Output:
>> >>
>> >> {'c': 'C', 'a': 'A', 't': 'T'}
>> >
>> > As does…
>> {c: c.upper() for c in s}
>> > {'a': 'A', 'c': 'C', 't': 'T'} : dict
>> >
>> > [Recent pythons; not sure when dict-comprehensions appeared]
>>
>> 3.0, and also backported to 2.7. So go ahead and use 'em.
>>
>> https://www.python.org/dev/peps/pep-0274/
>>
>> ChrisA
>> --
>> https://mail.python.org/mailman/listinfo/python-list
>>
>
>
--
https://mail.python.org/mailman/listinfo/python-list
Re: How to fill in a dictionary with key and value from a string?
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 are the keys sorted from upper case to lower case? I asked for lower
> case first, then upper case.
>
What version of which Python interpreter are you using? Dictionaries
aren't sorted by definition, but sometimes they do retain order.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: How to fill in a dictionary with key and value from a string?
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,
> > 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 for lower
> > case first, then upper case.
> >
>
> What version of which Python interpreter are you using? Dictionaries
> aren't sorted by definition, but sometimes they do retain order.
>
> ChrisA
> --
> https://mail.python.org/mailman/listinfo/python-list
>
--
https://mail.python.org/mailman/listinfo/python-list
Re: Why is the use of an undefined name not a syntax error?
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 all valid names in a .py file and in particular > to identify which names are not valid. Not even close. The bottom line is, the Python core developers don't want to spent their time writing and maintaining what is effectively a linter. Python is run by a small team of volunteers with relatively little funding, and there are far more important things for them to work on than duplicating the work done by linters. If you want something to check your code ahead of time for undefined names, then run a linter: you have many to choose from. But even if they were prepared to do so, it isn't as easy or cheap as you think. This sort of analysis works for local variables because Python has decided on the rule that *any* binding operation to a local name in a function makes it a local, regardless of whether that binding operation would actually be executed or not. So: def function(): len return None if False: len = len fails with UnboundLocalError. That's the rule for functions, and it is deliberately made more restrictive than for Python code outside of functions as a speed optimization. (In Python 3, the rule is more restrictive than for Python 2: star imports inside functions and unqualified exec are forbidden too.) But it doesn't work for globals unless you make unjustifiable (for the compiler) assumptions about what code contains, or do an extremely expensive whole-application analysis. For example, here's a simple, and common, Python statement: import math Can you tell me what global names that line will add to your globals? If you said only "math", then you're guilty of making those unjustifiable assumptions. Of course, for *sensible* code, that will be the only name added, but the compiler shouldn't assume the code is sensible. Linters can, but the compiler shouldn't. The imported module is not necessarily the standard library `math` module, it could be a user-defined module shadowing it. That module could have side-effects, and those side-effects could include populating the current module (not the fake `math`) with any number of globals, or adding/deleting names from the builtins. So the instant you import a module, in principle you no longer know the state of globals. Of course, in practice we don't do that. Much. But it is intentionally allowed, and it is not appropriate for the compile to assume that we never do that. A linter can assume sensible code, and get away with more false negatives than the compiler can. So here is a partial list of things which could change the global or built-in name spaces, aside from explicit binding operations: - star imports; - importing any module could inject names into builtins or your globals as a side-effect; - calling any function could do the same; - exec; - eval, since it could call exec; - manipulating globals() or locals(); - even under another name, e.g: foo = False or globals # later foo()['surprise'] = 12345 I've probably missed many. Of course sensible code doesn't do horrible things like those (possible excluding the star imports), but the compiler would have to cope with them since they are allowed and sometimes they're useful. Unlike a linter, which can afford to be wrong sometimes, the compiler cannot be wrong or it counts as a compiler bug. Nobody will be too upset if a linter misses some obscure case in obfuscated weird code. But if the compiler wrongly flags an error when the code is actually legal, people will be justifiably annoyed. -- Steve -- https://mail.python.org/mailman/listinfo/python-list
Re: How to fill in a dictionary with key and value from a string?
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 its corresponding value simultaneously on the
> fly?
Of course.
myDict = dict(zip("abcdefghijklmnopqrstuvwxyz",
"BCDEFGHIJKLMNOPQRSTUVWXYZA"))
--
Steve
--
https://mail.python.org/mailman/listinfo/python-list
Re: How to fill in a dictionary with key and value from a string?
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 < [email protected]> wrote: > 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 its corresponding value simultaneously on the > > fly? > > Of course. > > myDict = dict(zip("abcdefghijklmnopqrstuvwxyz", > "BCDEFGHIJKLMNOPQRSTUVWXYZA")) > > > > -- > Steve > > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: How to fill in a dictionary with key and value from a string?
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, am I right? You probably should be manipulating *strings*, not dicts. Do these examples help? py> import string py> letters = string.ascii_lowercase py> letters 'abcdefghijklmnopqrstuvwxyz' py> letters[1:] + letters[:1] 'bcdefghijklmnopqrstuvwxyza' py> letters[5:] + letters[:5] 'fghijklmnopqrstuvwxyzabcde' py> letters[23:] + letters[:23] 'xyzabcdefghijklmnopqrstuvw' Slice your strings into the order that you want, then put them in a dict for fast lookups by character. > I want to know/learn how to manipulate dictionary with loop and by its > position location. Dict entries don't have a position location except by accident, or in sufficiently new versions of Python, by insertion order. If you want to process dict entries in a specific order, operate on the dict in whichever order you want: ordered_keys = 'azbycxdwevfugthsirjqkplomn' for k in ordered_keys: print(mydict[k]) In Python 3.7, dicts will keep their insertion order, so long as you don't delete any keys. -- Steve -- https://mail.python.org/mailman/listinfo/python-list
Re: How to fill in a dictionary with key and value from a string?
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]))
How to debug a particular chunk of code?
Everything in OOP is self.myDict, self.shift_dict. So, I must run the
entire code to test.
I just want to try myDict('hello', 4), shift_dict(4), like how you would do
in C language.
Thank you!
On Sun, Apr 1, 2018 at 11:13 PM, Steven D'Aprano <
[email protected]> wrote:
> 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, am I right?
>
> You probably should be manipulating *strings*, not dicts. Do these
> examples help?
>
> py> import string
> py> letters = string.ascii_lowercase
> py> letters
> 'abcdefghijklmnopqrstuvwxyz'
> py> letters[1:] + letters[:1]
> 'bcdefghijklmnopqrstuvwxyza'
> py> letters[5:] + letters[:5]
> 'fghijklmnopqrstuvwxyzabcde'
> py> letters[23:] + letters[:23]
> 'xyzabcdefghijklmnopqrstuvw'
>
>
> Slice your strings into the order that you want, then put them in a dict
> for fast lookups by character.
>
>
> > I want to know/learn how to manipulate dictionary with loop and by its
> > position location.
>
> Dict entries don't have a position location except by accident, or in
> sufficiently new versions of Python, by insertion order.
>
> If you want to process dict entries in a specific order, operate on the
> dict in whichever order you want:
>
> ordered_keys = 'azbycxdwevfugthsirjqkplomn'
> for k in ordered_keys:
> print(mydict[k])
>
>
> In Python 3.7, dicts will keep their insertion order, so long as you
> don't delete any keys.
>
>
>
> --
> Steve
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
--
https://mail.python.org/mailman/listinfo/python-list
Re: How to fill in a dictionary with key and value from a string?
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 better off just using a list or a deque, although a SortedListWithKey http://www.grantjenks.com/docs/sortedcontainers/sortedlistwithkey.html is available if you really need it, although I'll admit to being very dubious about that. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Why is the use of an undefined name not a syntax error?
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 a .py file and in particular to identify which names are not valid. If broken name references were detected at compile time, it would eliminate a huge class of errors before running the program: missing imports, call of misspelled top-level function, reference to misspelled local variable. Of course running a full typechecker like mypy would eliminate more errors like misspelled method calls, type mismatch errors, etc. 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? - David P.S. Here are some uncommon language features that interfere with identifying all valid names. In their absence, one might expect an invalid name to be a syntax error: * import * * manipulating locals() or globals() * manipulating a frame object * eval The CPython parser and compiler are autogenerated from an LL(1) context-free grammer and other files. Context-dependent rules like the above are for linters and other whole-program analyses. A linter that makes occasional mistakes in its warning can still be useful. A compiler should be perfect. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: semicolon at end of python's statements
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 Well, if you have to program in both c and python, and switch between them on intervals of time lowers than some hours I would suggest keep on with the semicolons at the end of lines... It would be very difficult to lose that habit, and while it is inoffensive on python, it may cause some troubles on c. -- https://mail.python.org/mailman/listinfo/python-list
Re: Unified async/sync interface
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 (initially requests and aiohttp). So far,
> I've tried a few approaches with `async def` but, of course, you always
> run into the issue with the top level API that should either be async
> or not, but can't be redefined on the fly (AFAICT). I'm also trying to
> limit code duplication. I know I could write async and sync versions of
> each method and then instantiate through composition based on the
> transport layer but I'd like to avoid that if possible. As an
> simplified example of what I'm after:
>
> [code snipped]
>
> Is this perhaps possible through asyncio.coroutine decorators
> (admittedly, I haven't looked yet, I've had async/await blinders on)?
> Are there any projects that anyone's aware of that does anything
> similar that I could use as an example?
>
> The overall point of what I'm trying to achieve here is to write a
> client that's supported from 2.7 to 3.x and supports /either/
> synchronous or asynchronous transports (not both at the same time).
asyncio doesn't exist for 2.7 unless you're using trollius, which I
understand is an incomplete port and also currently unmaintained. Even
with trollius, I think that aiohttp is still going to restrict you to
3.5.3+. Unless your plan is to support synchronous transports only for
2.7. You definitely can't use "async def" with 2.7.
To answer your question though, it sounds like you need your
get_something method to return either the deserialized data if the
transport is synchronous, or an awaitable that will resolve to the
deserialized data when asynchronous. Since you don't want to implement
the logic twice, I suggest breaking down the logic into transforms
that can be applied generically, something like this (untested):
def get_something(self):
# Agnosticly get either synchronously fetched data
# or an async awaitable.
data = self.transport.get('https://example.com')
return self._transform(data, json.loads)
def _transform(self, value, func):
# Transform value using func either synchronously or
# asynchronously, depending on the transport regime.
if self.transport.is_async():
async def await_and_transform(awaitable):
new_value = func(await awaitable)
if inspect.isawaitable(new_value):
# In case func might also be async
return await new_value
else:
return new_value
return await_and_transform(value)
else:
return func(value)
Note that if the async framework might be something other than asyncio
then the above code probably wouldn't work. In that case perhaps it
would be better to let the transport define the async transformation
logic.
--
https://mail.python.org/mailman/listinfo/python-list
