|
Yeah I don't know it's how every hand calculator I've ever had has worked so it didn't surprise me at all.
|
# ? Apr 26, 2016 22:31 |
|
|
# ? May 9, 2024 14:04 |
|
Hed posted:Yeah I don't know it's how every hand calculator I've ever had has worked so it didn't surprise me at all. Hand... calculator? Like, you push buttons on a thing that only calculates?
|
# ? Apr 26, 2016 23:01 |
|
It can spell.... boobs.
|
# ? Apr 27, 2016 01:10 |
|
Tigren posted:Hand... calculator? Like, you push buttons on a thing that only calculates? You know how you prove an RCE with a screenshot of calc.exe? Well, that program was actually made into a handheld device, like a Tiger Electronics portable game but for an application. Edit: just for clarification, I don't think handheld calculators can be used to demonstrate an RCE unless the thing you hacked is a 3D printer.
|
# ? Apr 27, 2016 03:06 |
|
QuarkJets posted:To be fair, it's how most languages work under-the-hood. Even just written out on paper it's a bit ambiguous I believe that if I saw -2² written on paper I'd read it as -4 without thinking hard about it, and I'd expect to see (-2)² if it were to be evaluated the other way. Or to put it another way, I think in written mathematics the unary minus sign is just shorthand for "0 -" and with that understood, it works with the same precedence as subtraction usually has.
|
# ? Apr 27, 2016 14:31 |
|
Hey dudes. I know this is an area with many attempts and no popular results, but I'm trying to override datetimes. Ie a wrapper for datetime and pytz with easy syntax, but without some of the downfalls of attempts like Arrow. [slowness, requiring the user to call timezone libraries explicitly, and obtuse naming conventions etc] I suck at classes, but I think they're required h ere. Datetime objects' tzinfo attribute can't be set by a hard block, so I need to return a new one If I initiate a new instance, or convert a timezone-naive datetime. Here's my mess of confusion: Python code:
Python code:
Python code:
Dominoes fucked around with this message at 05:40 on Apr 29, 2016 |
# ? Apr 28, 2016 20:17 |
|
Not 100% I'm following what you want but to simply that, could you, inside your __init__ look for a tzinfo argument inside **kwargs, test it, and pass it on either as is or modified by your logic to super.__init__(*args, **kwargs)? Now if tzinfo can be given as a positional argument it's messier.
|
# ? Apr 28, 2016 22:25 |
|
Does anyone know if it is it possible to run UWSGI from a Raspberry Pi? AFAIK you can run PyPy on it, but I'm not sure if it just works with my current application set or if I have to whip up something else. I don't have a Pi or else I would test it myself.
|
# ? Apr 29, 2016 00:31 |
|
HardDisk posted:Does anyone know if it is it possible to run UWSGI from a Raspberry Pi? AFAIK you can run PyPy on it, but I'm not sure if it just works with my current application set or if I have to whip up something else. I can test it out if you tell me what I need to do for it. I'm installing UWSGI now on my pi2 edit: following this guide http://uwsgi-docs.readthedocs.io/en/latest/WSGIquickstart.html I was able to do the hello world successfully. creatine fucked around with this message at 02:53 on Apr 29, 2016 |
# ? Apr 29, 2016 02:48 |
|
Wow, thank you! Any specific headaches? Are you running Noobs or Raspbian? Do you have to run PyPy or does cPython work? Can you test Flask on it, please?
|
# ? Apr 29, 2016 03:47 |
|
HardDisk posted:Wow, thank you! NOOBS with the default python 2.7. Installing flask to try it. edit: so I don't really know flask at all so I don't really know what's supposed to go on with this. When I run a hello world flask app through uwsgi the console doesnt give any errors but I don't know what supposed to happen next This is what the console shows. creatine fucked around with this message at 04:09 on Apr 29, 2016 |
# ? Apr 29, 2016 03:52 |
|
It seems to be working to me. Try accessing localhost:8080.
|
# ? Apr 29, 2016 04:25 |
|
Connection refused error on localhost and with :8080 but I'm probably doing something wrong. Like I said I've never used flask or uwsgi before so I'm going in blind.
|
# ? Apr 29, 2016 04:27 |
|
Probably because it needs an nginx running as well. But uWSGI seems to be working. Thanks a lot for that!
|
# ? Apr 29, 2016 04:29 |
|
No problem! I can fiddle with getting nginx running tomorrow to test if it fully works too
|
# ? Apr 29, 2016 04:34 |
|
Dominoes posted:edit: This seems to be working. Is it OK? Not working - it looks like this is just returning a dt object that always has tzinfo, rather than my custom object. I tried this: Python code:
|
# ? Apr 29, 2016 18:06 |
|
I've honestly never seen __new__ used before (although I do know what it does)... but I think you need to use the cls input. The first line should be dt = cls(*args, **kwargs). Then you'll get your Instant object and not a regular datetime. I also like to use self for what you call dt when I'm writing an object-creation classmethod, to make it clear that it's for object creation. You also still have the same problem as before: you need to be passing datetime arguments to super().__init__(). In the first method, doing this might make the __new__ method unnecessary. In the second, you can set the datetime fields by passing them to super().__init__() rather than setting them as attributes (since perhaps datetime is immutable). I would also question using inheritance here at all, although I'm not an OOP wizard and try to avoid classes as much as possible. SurgicalOntologist fucked around with this message at 18:32 on Apr 29, 2016 |
# ? Apr 29, 2016 18:29 |
|
I highly recommend using functions and not custom subclasses of Python builtins.
|
# ? Apr 29, 2016 18:31 |
|
Suspicious Dish posted:I highly recommend using functions and not custom subclasses of Python builtins. SurgicalOntologist posted:I've honestly never seen __new__ used before (although I do know what it does)... but I think you need to use the cls input. The first line should be dt = cls(*args, **kwargs). Then you'll get your Instant object and not a regular datetime. I also like to use self for what you call dt when I'm writing an object-creation classmethod, to make it clear that it's for object creation. I'm trying a non-inheriting object that converts to datetime.datetime when added etc, but I suspect this will cause slowness, which is one of the complaints I have about Arrow. Dominoes fucked around with this message at 18:40 on Apr 29, 2016 |
# ? Apr 29, 2016 18:35 |
|
Your code will be inherently more fragile and harder to read if you do it this way, even if you do succeed in getting it to work. Write code that operates on normal datetime objects.
|
# ? Apr 29, 2016 18:42 |
|
Suspicious Dish posted:Your code will be inherently more fragile and harder to read if you do it this way, even if you do succeed in getting it to work. Write code that operates on normal datetime objects. Some of my goals: -Not slow like Arrow -Intuitive syntax. No strftime/strptime, no weird replace(days)/replace(day) stuff or jumping through hoops to localize. -Unsure if I want to merge dt/date/time. If I do, won't just set the unused parts to 0 like Arrow. -Clean format method to convert to/from string: no '%'s. -Iteration -Function-based rather than method-based -Don't deal with tz-naive dts. -One module to import: Wraps datetime and pytz, and doesn't require calling them separately. -Easy tz localization. Most of this should be pretty easy, and worth doing. Dominoes fucked around with this message at 18:53 on Apr 29, 2016 |
# ? Apr 29, 2016 18:43 |
|
Dominoes posted:I get max recursion errors when I do this: I think it's bouncing back between new and init indefinitely. Right, that makes sense. I see no reason you need the new though. Do any input mangling you need in init. Dominoes posted:I'm trying a non-inheriting object that converts to datetime.datetime when added etc, but I suspect this will cause slowness, which is one of the complaints I have about Arrow. Instead of an object that converts, what I had in mind was composition. Store the datetime as an attribute and you'll have much more freedom operating with it. In other words, make your class a wrapper of datetime rather than a modified datetime. But really, you should listen to Suspicious Dish.
|
# ? Apr 29, 2016 18:46 |
|
Both good ideas; both better than what I was trying to do. TBH I'm not sure what I would do with custom methods on top of datetime.datetime's, other than forcing the object to have a tzinfo. Here's your idea (having dt as an attribute rather than canning the custom object): Python code:
Dominoes fucked around with this message at 19:00 on Apr 29, 2016 |
# ? Apr 29, 2016 18:54 |
|
Oh, if forcing tzinfo is all you want to do that's probably overkill. In that case I would consider making a function that fakes being a class.Python code:
|
# ? Apr 29, 2016 19:01 |
|
That's slick too.
|
# ? Apr 29, 2016 19:06 |
|
the only thing you changed was a single letter
|
# ? Apr 29, 2016 19:09 |
|
I changed class to def. Is that not the kind of thing you had in mind when you encouraged using functions? Whether it's capitalized or not isn't really the issue; it may be better if it doesn't pretend to be a class to be honest.
|
# ? Apr 29, 2016 19:15 |
|
Yeah, my point is that he was somehow against functions, but when capitalizing it, suddenly it's super slick.
|
# ? Apr 29, 2016 19:44 |
|
Suspicious Dish posted:Yeah, my point is that he was somehow against functions Python code:
code:
|
# ? Apr 29, 2016 19:52 |
|
edit: Name change due to Pypi availability https://github.com/David-OConnor/saturn Basic documentation. The functionality it describes works atm except for string formatting (Uses strptime/strftime format until I can figure out the regex). Suggestions? Dominoes fucked around with this message at 19:15 on May 1, 2016 |
# ? Apr 29, 2016 21:40 |
|
It's always bothered me how slow Arrow and dateutil are. I've been limited by their speed many times. I haven't actually investigated to see whether the slowness is because of the way they are coded or if it's just inherent in the types of operations they do...but I'm glad someone else is working on it because gently caress dealing with dates and times.
|
# ? Apr 29, 2016 23:23 |
|
Same- not sure why Arrow's slow. I started using it for being always tz-aware, iteration, and curiosity about merging dates and dts. I was driven away by slowness, awkward syntax, lack of support for timedeltas, and requiring multiple imports. So far I've cleaned up irritating syntax and tz-naive pitfalls that affect my own code. What functionality do you think would be useful, besides what I've listed on the github page? Dominoes fucked around with this message at 19:57 on Apr 30, 2016 |
# ? Apr 30, 2016 06:48 |
|
Would it maybe make more sense to try investigating and improving Arrow's efficiency, rather than making a new class that replicates the same functionality but faster? It could be a real shitshow and you might get roadblocked, but if you're successful then it would help a lot more people
|
# ? Apr 30, 2016 19:56 |
|
QuarkJets posted:Would it maybe make more sense to try investigating and improving Arrow's efficiency, rather than making a new class that replicates the same functionality but faster? It could be a real shitshow and you might get roadblocked, but if you're successful then it would help a lot more people Does anyone have a guess as to why Arrow's slow? I picked an arbitrary task to demonstrate: Python code:
Dominoes fucked around with this message at 20:19 on Apr 30, 2016 |
# ? Apr 30, 2016 20:01 |
|
From https://github.com/crsmithdev/arrow/blob/master/arrow/arrow.py 1) It looks like replace() creates an entire new Arrow instance with updated attributes instead of just updating the attributes of the current Arrow instance. This might not be the worst idea, if there's a good reason for it. 2) Inside of replace() there's a big ugly comparison between the strings in kwargs and the strings in two internal lists, _ATTRS and _ATTRS_PLURAL. This happens every time that replace() is called. Yikes. Replacing those ATTR lists with sets would speed up the comparisons significantly, but it looks like the fact that these are lists in a specific order might be used elsewhere (in which case they could probably use OrderedDict and still get a huge speedup, but that's sloppy; is there really no OrderedSet anywhere in core Python?). This right here is probably the bulk of the problem
|
# ? Apr 30, 2016 20:40 |
|
Good find! Regarding point 1, I'm guessing it's to imitate datetime.datetime's immutability.
|
# ? Apr 30, 2016 20:49 |
|
It might be fun just to try it. "Hey I turned these lists into OrderedDict objects and the speedup was insane. Patch?"
|
# ? May 1, 2016 03:25 |
|
No reason not to. You already understand the issue - give it a go! Edit: Poking through Arrow's code, I noticed that formatting as a string requires creating a datetime object and changing its timezone... I'm guessing this library isn't designed with speed as a goal. Do y'all think these these func arguments should be set up with the most important arguments first (ie the datetime), per convention, or with the ones that are less likely to change first, which would make partial/currying easier? Ie: Python code:
Why would you they this: Python code:
Python code:
Dominoes fucked around with this message at 19:37 on May 1, 2016 |
# ? May 1, 2016 11:49 |
|
Is DateTimeFormatter used in a lot of other places? This might just be a one-time cludge to call a class method as a function, which is fine if the class method needs to be used as a class method in other places. Or it could just be someone going overboard with OO programming
|
# ? May 1, 2016 21:00 |
|
|
# ? May 9, 2024 14:04 |
|
No, only in the place I mentioned.
|
# ? May 1, 2016 21:27 |