Re: I really liked this Javscript FizzBuzz can it be as nice in Python?
On Fri, Apr 5, 2019 at 5:56 PM Sayth Renshaw wrote:
>
> I saw this fizzbuzz in Eloquent Javascript and thought its really nice. Not
> all the usual if else version, just if.
>
> for (let n = 1; n <= 100; n++) {
> let output = "";
> if (n % 3 == 0) output += "Fizz";
> if (n % 5 == 0) output += "Buzz";
> console.log(output || n);
> }
>
> I can't quite get a nice version like this out.
>
> This was my attempt to mimick it. I am sure Python can get it cleaner, but I
> had never thought about not doing if else for Fizzbuzz its just the way I did
> it.
>
> n = range(100)
> output = ""
> for num in n:
> if (num % 3 == 0): output += "Fizz"
> if (num % 5 == 0): output += "Buzz"
> print(output or num)
>
> Haven't quite got it. But is possible nice and succinct like the javascript
> version. Maybe lambda will do it, gonna try that.
I'd recommend a more direct transformation, specifically resetting
'output' inside the loop. Otherwise, you basically have the same code.
> Any unique mindlowing style FizzBuzz I would never have considered and can
> learn off?
>
print(*[[n,"Fizz","Buzz","Fizzbuzz"][int("300102100120100"[n%15])] for
n in range(1,101)], sep="\n")
This is not good code, and if anyone asks, I didn't say you were
allowed to do this in an interview.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Logging cf Reporting = Friday Filosofical Finking
On 4/4/2019 3:34 PM, DL Neil wrote:
> ("oh, and it would be nice if you could send the file to me by email..."
> - they're always, um, never, (quite) satisfied...)
I refer to this as the Heisenberg Principle of computer programming: the
act of giving a user what he says he wants changes what he wants.
Ben
--
Ben Coleman olo...@benshome.net | For the wise man, doing right trumps
http://oloryn.benshome.net/ | looking right. For the fool, looking
Amateur Radio NJ8J | right trumps doing right.
signature.asc
Description: OpenPGP digital signature
--
https://mail.python.org/mailman/listinfo/python-list
Re: I really liked this Javscript FizzBuzz can it be as nice in Python?
On 4/5/2019 2:52 AM, Sayth Renshaw wrote:
for (let n = 1; n <= 100; n++) {
n = range(100)
n = range(1, 101) to cover 1 to 100 inclusive
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
Re: I really liked this Javscript FizzBuzz can it be as nice in Python?
Sayth Renshaw wrote:
> I saw this fizzbuzz in Eloquent Javascript and thought its really nice.
> Not all the usual if else version, just if.
>
> for (let n = 1; n <= 100; n++) {
> let output = "";
> if (n % 3 == 0) output += "Fizz";
> if (n % 5 == 0) output += "Buzz";
> console.log(output || n);
> }
> Any unique mindlowing style FizzBuzz I would never have considered and can
> learn off?
Here's some itertools gymnastics ;)
from itertools import *
def make(s, n):
return cycle(chain(repeat("", n-1), (s,)))
fizzbuzz = map("".join, zip(make("Fizz", 3), make("Buzz", 5)))
for i, fb in enumerate(islice(fizzbuzz, 100), 1):
print(fb or i)
--
https://mail.python.org/mailman/listinfo/python-list
Re: I really liked this Javscript FizzBuzz can it be as nice in Python?
Wow in both of these examples I have no idea what is happening. Enjoying trying
to figure it out :-)
> print(*[[n,"Fizz","Buzz","Fizzbuzz"][int("300102100120100"[n%15])] for
> n in range(1,101)], sep="\n")
> This is not good code, and if anyone asks, I didn't say you were
> allowed to do this in an interview.
Sorry too late that was yesterday, they loved it :-)
> Here's some itertools gymnastics ;)
>
> from itertools import *
>
> def make(s, n):
> return cycle(chain(repeat("", n-1), (s,)))
>
> fizzbuzz = map("".join, zip(make("Fizz", 3), make("Buzz", 5)))
>
> for i, fb in enumerate(islice(fizzbuzz, 100), 1):
> print(fb or i)
Thanks
Sayth
--
https://mail.python.org/mailman/listinfo/python-list
Re: From parsing a class to code object to class to mappingproxy to object (oh my!)
adam.pre...@gmail.com wrote: Something I don't really understand from a code generation perspective is the switch over to STORE_NAME for class methods. That's because, in this particular situation, the locals are being kept in a dict instead of an array. When compiling an ordinary function, the compiler figures out what locals there are, and generates LOAD_FAST and STORE_FAST opcodes to access them by index. But when compiling a class body, it uses a dict to hold the locals, and generates LOAD_NAME and STORE_NAME opcodes to access it. These opcodes actually date from very early versions of Python, when locals were always kept in a dict. When optimised locals were introduced, the old mechanism was kept around for building class dicts. (There used to be one or two other uses, but I think classes are the only one left now.) -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Getting file extensions [linux fs]
Have you looked into eBPF? They have mature Python bindings. It makes interacting with the kernel as efficient as possible - you can run it in production at high resolutions without putting things at risk. One of the benefits - any averaging / aggregation / histograms / etc can be done by the kernel within the eBPF runtime, then passed back to python using eBPF "maps" - the link between your userspace program and the eBPF kernel code. From python this "map" is just a dict. You'll need to be running at least kernel version 4.4 to get the basic functionality, but ideally 4.9 or higher for all the newer and stable features. No dependencies, its baked into the kernel. You will need clang support to compile stuff, if you want to build modules on your own. *Pablo Lucena* On Sat, Mar 30, 2019 at 8:30 PM Paulo da Silva < p_s_d_a_s_i_l_v_a...@netcabo.pt> wrote: > Às 22:18 de 28/03/19, Cameron Simpson escreveu: > > On 28Mar2019 01:12, Paulo da Silva > wrote: > >> Às 23:09 de 27/03/19, Cameron Simpson escreveu: > ... > > > > > Oh, just tangential to this. > > > > If you were doing this ad hoc, yes calling the filefrag executable is > > very expensive. But if you are always doing a large batch of filenames > > invoking: > > > > filefrag lots of filenames here ...> > > and reading from its output can be very effective, because the expense > > of the executable is amortized over all the files - the per file cost is > > much reduced. And it saves you working out how to use the ioctls from > > Python :-) > That's not the case. > I need to do it on some files basis which I don't know in advance. > Using IOCTL, I don't need to parse or unpack the output. Only compare > the output arrays. Besides I need to store many of the outputs. Doing > that from filefrag text output would be unpractical. I needed, at least, > to compress the data. Although may be I might have to compress the ioctl > arrays ... Let's see how big in average is the storage needed. > > I have to go with ioctl. I have to open the files anyway, so there is no > overhead for that when calling the ioctl. > > Anyway, thank you for the suggestion. > > Regards. > Paulo > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: hello this ali .. i want some question about python
On Saturday, 6 April 2019 08:21:51 UTC+11, maak khan wrote: > i need your help guys .. plz With? -- https://mail.python.org/mailman/listinfo/python-list
hello this ali .. i want some question about python
i need your help guys .. plz -- https://mail.python.org/mailman/listinfo/python-list
Re: hello this ali .. i want some question about python
Hi, On Fri, Apr 5, 2019 at 9:02 PM Sayth Renshaw wrote: > > On Saturday, 6 April 2019 08:21:51 UTC+11, maak khan wrote: > > i need your help guys .. plz Are you trying to create a teaching software? Thank you. > > With? > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: From parsing a class to code object to class to mappingproxy to object (oh my!)
On Friday, April 5, 2019 at 5:54:42 PM UTC-5, Gregory Ewing wrote: > But when compiling a class body, it uses a dict to hold the > locals, and generates LOAD_NAME and STORE_NAME opcodes to > access it. > > These opcodes actually date from very early versions of > Python, when locals were always kept in a dict. When > optimised locals were introduced, the old mechanism was kept > around for building class dicts. (There used to be one or > two other uses, but I think classes are the only one left > now.) Thanks for the explanation. I've figured from this that I could do most variable access by just generating LOAD/STORE_NAME and the FAST is an (important) optimization. That is disregarding sneaking in the global or nolocal keywords... So let's say I'm generating byte codes. If I am generating code for a class body, then I have a dictionary and I'm generating LOAD/STORE NAMEs. Any other body is usually going to wind up being FAST/GLOBAL/the other ones. An important exception there would be for built-ins and presumably imported stuff, right? I'm asking because right now I've literally hard-coded some logic that tells me if I'm generating a class body so I know to use names. I just feel kind of silly doing that. -- https://mail.python.org/mailman/listinfo/python-list
