RE: Which more Pythonic - self.__class__ or type(self)?

>>> I think you are over-thinking this, Avi :) Is overthinking the pythonic way or did I develop such a habit from some other language? More seriously, I find in myself that I generally do not overthink. I overtalk and sort of overwrite, so for now, I think I will drop out of this pos

Re: Which more Pythonic - self.__class__ or type(self)?

Nope. No consensus. I’d use self.__class__ . Seems more explicit and direct to me. From: Python-list on behalf of Ian Pilcher Date: Thursday, March 2, 2023 at 4:17 PM To: python-list@python.org Subject: Which more Pythonic - self.__class__ or type(self)? *** Attention: This is an external

Re: Which more Pythonic - self.__class__ or type(self)?

a multidimensional numpy/pandas kind of data structure. So ignoring the word pythonic as too specific, is there a way to say that something is the way your current language supports more naturally? Yes, there are sort of fingerprints in how people write. Take the python concept of truthy and how

RE: RE: Which more Pythonic - self.__class__ or type(self)?

it becomes an exotic addition to Python in a way that loosely melds, or if it becomes the PYTHONIC way ... -Original Message- From: Alan Gauld Sent: Saturday, March 4, 2023 1:38 PM To: avi.e.gr...@gmail.com; python-list@python.org Subject: Re: RE: Which more Pythonic - self.__class__ or

RE: Which more Pythonic - self.__class__ or type(self)?

find a dozen former languages are simply not enough. - Python for people who really want to mainly use the modules like pandas or sklearn ... - Pythonic upgrades to the methods used in former inferior languages ... - How to speak with a Pythonese accent and lose you old accent based on your former

RE: Which more Pythonic - self.__class__ or type(self)?

structure. So ignoring the word pythonic as too specific, is there a way to say that something is the way your current language supports more naturally? Yes, there are sort of fingerprints in how people write. Take the python concept of truthy and how some people will still typically add a test

Re: Which more Pythonic - self.__class__ or type(self)?

" > or "scenic" as compared to the way people keep saying "pythonic". Oh, you're talking about the term, not the concept? You may have something there. I remember lots of discussions about "idiomatic C" or "idiomatic Perl", but not about "

Re: RE: Which more Pythonic - self.__class__ or type(self)?

On 04/03/2023 17:38, avi.e.gr...@gmail.com wrote: > > Of course each language has commonly used idioms > That's the point, the correct term is probably "idiomatic" rather than "pythonic" but it is a defacto standard that idiomatic Python has become known as P

Re: Which more Pythonic - self.__class__ or type(self)?

On 04/03/2023 20.47, Peter J. Holzer wrote: On 2023-03-03 13:51:11 -0500, avi.e.gr...@gmail.com wrote: ... No. Even before Python existed there was the adage "a real programmer can write FORTRAN in any language", indicating that idiomatic usage of a language is not governed by syntax and

Re: Which more Pythonic - self.__class__ or type(self)?

On 3/4/2023 2:47 AM, Peter J. Holzer wrote: Even before Python existed there was the adage "a real programmer can write FORTRAN in any language", indicating that idiomatic usage of a language is not governed by syntax and library alone, but there is a cultural element: People writing code in a

RE: Which more Pythonic - self.__class__ or type(self)?

Peter, Of course each language has commonly used idioms as C with pointer arithmetic and code like *p++=*q++ but my point is that although I live near a seaway and from where C originated, I am not aware of words like "c-way" or "scenic" as compared to the way people keep say

Re: Which more Pythonic - self.__class__ or type(self)?

On 2023-03-03 13:51:11 -0500, avi.e.gr...@gmail.com wrote: > I do not buy into any concept about something being pythonic or not. > > Python has grown too vast and innovated quite a bit, but also borrowed from > others and vice versa. > > There generally is no universall

Re: Which more Pythonic - self.__class__ or type(self)?

On 4/03/23 7:51 am, avi.e.gr...@gmail.com wrote: I leave you with the question of the day. Was Voldemort pythonic? Well, he was fluent in Parseltongue, which is not a good sign. I hope not, otherwise we'll have to rename Python to "The Language That Shall Not Be Named" and

RE: Which more Pythonic - self.__class__ or type(self)?

Alan, I do not buy into any concept about something being pythonic or not. Python has grown too vast and innovated quite a bit, but also borrowed from others and vice versa. There generally is no universally pythonic way nor should there be. Is there a C way and then a C++ way and an R way

Re: Which more Pythonic - self.__class__ or type(self)?

haven't found >>> anything that talks about which form is considered to be more Pythonic >>> in those situations where there's no functional difference. >> >> I think avoiding dunder methods is generally considered more Pythonic. Outside of writing dunder methods, I tend

Re: Which more Pythonic - self.__class__ or type(self)?

which form is considered to be more Pythonic > > in those situations where there's no functional difference. > > I think avoiding dunder methods is generally considered more Pythonic. > > But in this specific case using isinstance() is almost always > the better option. Testing f

Re: Which more Pythonic - self.__class__ or type(self)?

On 02/03/2023 20:54, Ian Pilcher wrote: > Seems like an FAQ, and I've found a few things on StackOverflow that > discuss the technical differences in edge cases, but I haven't found > anything that talks about which form is considered to be more Pythonic > in those situations w

RE: Which more Pythonic - self.__class__ or type(self)?

My understanding is that python created functions like type() and len() as a general purpose way to get information and ALSO set up a protocol that classes can follow by creating dunder methods. I think the most pythonic things is to avoid directly calling the dunder methods with a few exceptions

Re: Which more Pythonic - self.__class__ or type(self)?

On 3/2/2023 5:53 PM, Greg Ewing via Python-list wrote: On 3/03/23 9:54 am, Ian Pilcher wrote: I haven't found anything that talks about which form is considered to be more Pythonic in those situations where there's no functional difference. In such cases I'd probably go for type(x), because

Re: Which more Pythonic - self.__class__ or type(self)?

On 3/03/23 9:54 am, Ian Pilcher wrote: I haven't found anything that talks about which form is considered to be more Pythonic in those situations where there's no functional difference. In such cases I'd probably go for type(x), because it looks less ugly. x.__class__ *might* be slightly more

Re: Which more Pythonic - self.__class__ or type(self)?

On 3/2/2023 3:54 PM, Ian Pilcher wrote: Seems like an FAQ, and I've found a few things on StackOverflow that discuss the technical differences in edge cases, but I haven't found anything that talks about which form is considered to be more Pythonic in those situations where there's no functional

Which more Pythonic - self.__class__ or type(self)?

Seems like an FAQ, and I've found a few things on StackOverflow that discuss the technical differences in edge cases, but I haven't found anything that talks about which form is considered to be more Pythonic in those situations where there's no functional difference. Is there any consensus

[Python-announce] Lona: a simple pythonic framework to write responsive web apps in full Python

side. If you want to have client side interaction like click events or you want update content live, you have to write an additional Javascript application. Lona handles the server side and the client side, and provides a simple, pythonic API to write self contained views. Lona is very easy to use

Pythonic way to run the asyncio loop forever in python 3.10

outside the loop. While doing so, I have bumped against some common (I think) use-cases which seem to have no elegant solution anymore. At least I can't find one that seems "pythonic" or "correct". Problem: Before 3.10, asyncio.get_event_loop() was a convenient way to manag

[issue493628] import not pythonic in 2.1.1

Change by admin : -- github: None -> 35749 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue47130] mro and super don't feel so pythonic

Ken Jin added the comment: Hi @mamliteria, this is the bug tracker for CPython. I understand that you have suggestions to improve super(), but feature suggestions usually go on the python-ideas mailing list [1]. So you might want to post on there instead. If you're interested, the MRO

[issue47130] mro and super don't feel so pythonic

New submission from malmiteria : Hi, Before anything, i made a github repository about this topic here : https://github.com/malmiteria/super-alternative-to-super The core of what i wanna discuss here is that i don't think mro and super (mainly because it relies on mro) are very pythonic

[issue42069] Make filecmp more pythonic

Raymond Hettinger added the comment: In general, we don't accept patches like this: * It risks breaks (in fact the tests are failing. * We're not apply Black's quoting preferences to existing files. * We're not yet adding type annotations through out. * The PR introduces multiple new

[issue42069] Make filecmp more pythonic

Change by Alex : -- keywords: +patch pull_requests: +21712 stage: -> patch review pull_request: https://github.com/python/cpython/pull/22750 ___ Python tracker ___

[issue42069] Make filecmp more pythonic

New submission from Alex : Cleanup the filecmp file add typing and make it more pythonic -- components: Library (Lib) messages: 378877 nosy: alex.briskin priority: normal severity: normal status: open title: Make filecmp more pythonic versions: Python 3.9

Re: Pythonic style

n't it apply? Can you elaborate on this? It might be easier > to advise on Pythonic style when the specific requirements are known. > No specific requirement. These are *finger exercises* intended to isolate one issue for discussion rather than be useful in themselves. > > ...but th

Re: Pythonic style

*use > tuple unpacking, on the theory that the coding patterns may be useful in > other cases where unpacking doesn't apply. When doesn't it apply? Can you elaborate on this? It might be easier to advise on Pythonic style when the specific requirements are known. > For me, one of the interes

Re: Pythonic style

: raise ValueError("first1: arg not exactly 1 long") But I don't know if the *_uniq* technique is considered Pythonic. If *next* were instead defined to return a flag (rather than raising an exception), the code becomes cleaner and clearer, something like this: def firsth(iterable):

Re: Pythonic style

Thanks, Tim! I didn't realize that you could write (x,) on the LHS! Very nice, very Pythonic! -s On Mon, Sep 21, 2020 at 9:15 AM Tim Chase wrote: > On 2020-09-20 18:34, Stavros Macrakis wrote: > > Consider a simple function which returns the first element of an >

Re: Pythonic style

this function in multiple ways, all of which feel a bit clumsy. The 'obvious' thing to me was the double try-except StopIteration. It is clear, and clarity is 'pythonic'. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list

Re: Pythonic style

work even if the iterable doesn't terminate. I've written this function in multiple ways, all of which feel a bit clumsy. I'd be interested to hear thoughts on which of these solutions is most Pythonic in style. And of course if there is a more elegant way to solve this, I'm all ears! I'm probably

Re: Pythonic style

On 2020-09-21 09:48, Stavros Macrakis wrote: >> def fn(iterable): >> x, = iterable >> return x > > Thanks, Tim! I didn't realize that you could write (x,) on the LHS! > Very nice, very Pythonic! It also expands nicely for other cases, so you want th

Re: Pythonic style

On 21/09/2020 15:15, Tim Chase wrote: > You can use tuple unpacking assignment and Python will take care of > the rest for you: > > so you can do > > def fn(iterable): > x, = iterable > return x > > I'm not sure it qualifies as Pythonic, but it uses

Re: Pythonic style

if the iterable doesn't terminate. > > I've written this function in multiple ways, all of which feel a > > bit clumsy. > > > > I'd be interested to hear thoughts on which of these solutions is > > most Pythonic in style. And of course if there is a more elegant >

Re: Pythonic style

le ways, all of which feel a > bit clumsy. > > I'd be interested to hear thoughts on which of these solutions is > most Pythonic in style. And of course if there is a more elegant > way to solve this, I'm all ears! I'm probably missing something > obvious! You can use tuple u

Re: Pythonic style

terminate. I've written this function in > multiple ways, all of which feel a bit clumsy. > > I'd be interested to hear thoughts on which of these solutions is most > Pythonic in style. And of course if there is a more elegant way to solve > this, I'm all ears! I'm probably missing som

Pythonic style

a bit clumsy. I'd be interested to hear thoughts on which of these solutions is most Pythonic in style. And of course if there is a more elegant way to solve this, I'm all ears! I'm probably missing something obvious! Thanks, -s def firsta(iterable): it = iter(iterable) try

[issue41077] Make Cookiejar a bit more pythonic

Rémi Lapeyre added the comment: Hi Srinivas, as I said on the PR, cosmetic changes are usually not accepted. You can have a look at the other opened bug reports to find issues you can work on and at the Python Dev Guide (https://devguide.python.org/) for help to get started hacking Python!

[issue41077] Make Cookiejar a bit more pythonic

Change by Srinivas Reddy Thatiparthy(శ్రీనివాస్ రెడ్డి తాటిపర్తి) : -- resolution: -> wont fix stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue41077] Make Cookiejar a bit more pythonic

Srinivas Reddy Thatiparthy(శ్రీనివాస్ రెడ్డి తాటిపర్తి) added the comment: I am not sure this PR will be accepted. If you are a core dev, and thinks this is not Okay, please feel free close this issue. -- keywords: +patch message_count: 1.0 -> 2.0 pull_requests: +20226 stage: ->

[issue41077] Make Cookiejar a bit more pythonic

New submission from Srinivas Reddy Thatiparthy(శ్రీనివాస్ రెడ్డి తాటిపర్తి) : Title says it all. -- messages: 372087 nosy: thatiparthy priority: normal severity: normal status: open title: Make Cookiejar a bit more pythonic ___ Python tracker

Re: What about idea of making a "Pythonic Lisp"...i.e. a Lisp that more closely resembles the syntax of Python?

On Fri, Sep 20, 2019 at 5:16 AM Cecil Westerhof wrote: > > Paul Rubin writes: > > > Python 3.7.3 (default, Apr 3 2019, 05:39:12) > > Type "help", "copyright", "credits" or "license" for more information. > > >>> a = range(10) > > >>> b = reversed(a) > > >>> sum(a) == sum(b)

Re: What about idea of making a "Pythonic Lisp"...i.e. a Lisp that more closely resembles the syntax of Python?

Paul Rubin writes: > Python 3.7.3 (default, Apr 3 2019, 05:39:12) > Type "help", "copyright", "credits" or "license" for more information. > >>> a = range(10) > >>> b = reversed(a) > >>> sum(a) == sum(b) > True > >>> sum(b) == sum(a) > False Why does this

Re: What about idea of making a "Pythonic Lisp"...i.e. a Lisp that more closely resembles the syntax of Python?

goto main; Blogging at http://blogologue.com Tweeting at https://twitter.com/blogologue On Instagram https://instagram.com/morphexx søn. 15. sep. 2019, 03.07 skrev Christian Seberino : > Python is my goto main language. However, sometimes I'm tempted to > play with a Lisp like language just

Re: What about idea of making a "Pythonic Lisp"...i.e. a Lisp that more closely resembles the syntax of Python?

On 9/15/19 9:10 AM, Christian Seberino wrote: > Say if I may ask a tangential question...I've always wondered whether it > would be not too hard to compile Python source code to a Lisp like source > code? How hard would it be to say compile Python source to Clojure source? I'm sure a compiler

Re: What about idea of making a "Pythonic Lisp"...i.e. a Lisp that more closely resembles the syntax of Python?

gt; flavor that was closer to Python. Then, later converting that "Pythonic > Lisp" to Clojure later. That "Pythonic Lisp" is what I was thinking about. > > Cheers, > > Chris > > -- > https://mail.python.org/mailman/listinfo/python-list -- Luciano R

Re: What about idea of making a "Pythonic Lisp"...i.e. a Lisp that more closely resembles the syntax of Python?

> Python vs Clojure's syntax difference is superficial compared to their > other differences, like the Clojure's immutable data structures and > having to deal with the JVM. Well there's ClojureScript to run this hypothetical Pythonic Lisp in the browser. > I also don't think

Re: What about idea of making a "Pythonic Lisp"...i.e. a Lisp that more closely resembles the syntax of Python?

ing Python source code to Clojure source. Imagine instead compiling Python source to an intermediate Lisp flavor that was closer to Python. Then, later converting that "Pythonic Lisp" to Clojure later. That "Pythonic Lisp" is what I was thinking about. Cheers, Chris --

Re: What about idea of making a "Pythonic Lisp"...i.e. a Lisp that more closely resembles the syntax of Python?

On 9/14/19 8:19 PM, Louis Valence wrote: > I had to read this twice. It confused the hell out of me. Anyhow, I > suppose you should take a look at > > https://github.com/hylang/hy Yup that's probably exactly the opposite of what the OP was asking about. Neat, though. --

Re: What about idea of making a "Pythonic Lisp"...i.e. a Lisp that more closely resembles the syntax of Python?

Christian Seberino writes: > Python is my goto main language. However, sometimes I'm tempted to > play with a Lisp like language just for fun. > > Clojure looks pretty solid but its syntax is different than Python's. > > Since Lisp's make it so easy to modify the language, what about the idea >

What about idea of making a "Pythonic Lisp"...i.e. a Lisp that more closely resembles the syntax of Python?

Python is my goto main language. However, sometimes I'm tempted to play with a Lisp like language just for fun. Clojure looks pretty solid but its syntax is different than Python's. Since Lisp's make it so easy to modify the language, what about the idea of developing a few macros to make a

Re: Pythonic custom multi-line parsers

On 7/10/19 10:50 AM, Johannes Bauer wrote: Hi list, I'm looking for ideas as to a pretty, Pythonic solution for a specific problem that I am solving over and over but where I'm never happy about the solution in the end. It always works, but never is pretty. So see this as an open-ended

Pythonic custom multi-line parsers

Hi list, I'm looking for ideas as to a pretty, Pythonic solution for a specific problem that I am solving over and over but where I'm never happy about the solution in the end. It always works, but never is pretty. So see this as an open-ended brainstorming question. Here's the task: There's

Re: Most "pythonic" syntax to use for an API client library

I highly recommend going with the last approach. With the last approach you can pass around objects in proper OOP fashion. This will be familiar to most contributors to your project and most devs that you hire. foo = api.customers(1) if bar==baz: foo.update(Name='Leroy') else:

Re: Most "pythonic" syntax to use for an API client library

Le dim. 28 avr. 2019 à 20:58, Jonathan Leroy - Inikup a écrit : > Which of the following syntax do you expect an API client library to > use, and why? Thank you all for your feedbacks! I will go with #2. Le lun. 29 avr. 2019 à 05:43, DL Neil a écrit : > Doesn't the framework you are using

Re: Most "pythonic" syntax to use for an API client library

On 30/04/2019 09.52, Peter Otten wrote: > Thomas Jollans wrote: > >> On 29/04/2019 09.18, Peter Otten wrote: >>> Jonathan Leroy - Inikup via Python-list wrote: >>> alice.name = "Bob" # __setattr__ >>> >>> del customers[42] # __delitem__ >> >> do you want this sort of thing to update the

Re: Most "pythonic" syntax to use for an API client library

Thomas Jollans wrote: > On 29/04/2019 09.18, Peter Otten wrote: >> Jonathan Leroy - Inikup via Python-list wrote: >> >>> Hi all, >>> >>> I'm writing a client library for a REST API. The API endpoints looks >>> like this: /customers >>> /customers/1 >>> /customers/1/update >>> /customers/1/delete

Re: Most "pythonic" syntax to use for an API client library

On 29/04/2019 09.18, Peter Otten wrote: > Jonathan Leroy - Inikup via Python-list wrote: > >> Hi all, >> >> I'm writing a client library for a REST API. The API endpoints looks like >> this: /customers >> /customers/1 >> /customers/1/update >> /customers/1/delete >> >> Which of the following

Re: Most "pythonic" syntax to use for an API client library

Jonathan Leroy - Inikup via Python-list wrote: > Hi all, > > I'm writing a client library for a REST API. The API endpoints looks like > this: /customers > /customers/1 > /customers/1/update > /customers/1/delete > > Which of the following syntax do you expect an API client library to > use,

Re: Most "pythonic" syntax to use for an API client library

On 29 Apr 2019 07:18, DL Neil wrote: On 29/04/19 4:52 PM, Chris Angelico wrote: > On Mon, Apr 29, 2019 at 2:43 PM DL Neil > wrote: >> >> On 29/04/19 3:55 PM, Chris Angelico wrote: >>> On Mon, Apr 29, 2019 at 1:43 PM DL Neil >>> wrote: Well, seeing you ask: a more HTTP-ish approach

Re: Most "pythonic" syntax to use for an API client library

- something like: api.post("customer", {...}) api.get("customer", 1) api.patch("customer", 1, {...}) And that's fine if what you want is HTTP. But if you want something a bit more Pythonic, you want something that more adequately represents the underlying concepts, not th

Re: Most "pythonic" syntax to use for an API client library

> ...shouldn't the Python-like interface reflect what it is wrapping? It should. But if you just want an HTTP-like interface, you don't really need much of a wrapper. All you need is a hyperthin wrapper around the requests library - something like: api.post("customer", {...}) ap

Re: Most "pythonic" syntax to use for an API client library

On 29/04/19 3:55 PM, Chris Angelico wrote: On Mon, Apr 29, 2019 at 1:43 PM DL Neil wrote: Well, seeing you ask: a more HTTP-ish approach *might* be: api.update.customer( 1, name='Bob' ) ie api.verb.subject( adjectives and adverbs ) Thus:

Re: Most "pythonic" syntax to use for an API client library

On Mon, Apr 29, 2019 at 1:43 PM DL Neil wrote: > Well, seeing you ask: a more HTTP-ish approach *might* be: > > api.update.customer( 1, name='Bob' ) > > ie > api.verb.subject( adjectives and adverbs ) > > Thus: > api_label/intro/ID.what_we're_going_to_do.who/what_we'll_do_it_to( > customerID,

Re: Most "pythonic" syntax to use for an API client library

On 29/04/19 6:58 AM, Jonathan Leroy - Inikup via Python-list wrote: 1/ api.customers_list() api.customers_info(1) api.customers_update(1, name='Bob') api.customers_delete(1) Dislike this because it mixes point and underscore - easy to mistake! 2/ api.customers.list() api.customers.info(1)

Re: Most "pythonic" syntax to use for an API client library

On Mon, Apr 29, 2019 at 11:44 AM Jonathan Leroy - Inikup via Python-list wrote: > > Hi all, > > I'm writing a client library for a REST API. The API endpoints looks like > this: > /customers > /customers/1 > /customers/1/update > /customers/1/delete > > Which of the following syntax do you

Most "pythonic" syntax to use for an API client library

Hi all, I'm writing a client library for a REST API. The API endpoints looks like this: /customers /customers/1 /customers/1/update /customers/1/delete Which of the following syntax do you expect an API client library to use, and why? 1/ api.customers_list() api.customers_info(1)

Re: more pythonic way

On 2019-02-16, Barry wrote: > On 11 Feb 2019, at 20:00, Felix Lazaro Carbonell wrote: > >>> The most pythonic way is to do this: >>> >>> def find_monthly_expenses(month=datetime.date.today().month, >> year=datetime.date.today().year): >>>

Re: more pythonic way

On 11 Feb 2019, at 20:00, Felix Lazaro Carbonell wrote: >> The most pythonic way is to do this: >> >> def find_monthly_expenses(month=datetime.date.today().month, > year=datetime.date.today().year): >>... This has subtle bugs. The default i

Re: more pythonic way

The first one is used very often. Less verbose Le 11 févr. 2019 à 20:41, à 20:41, Felix Lazaro Carbonell a écrit: > > >Hello to everyone: > >Could you please tell me wich way of writing this method is more >pythonic: > > > >.. > >def find_mo

Re: more pythonic way

Felix Lazaro Carbonell wrote: > Hello to everyone: > Could you please tell me wich way of writing this method is more pythonic: > def find_monthly_expenses(month=None, year=None): > > month = month or datetime.date.today() > Or it should better be: >

Re: more pythonic way

Grant Edwards wrote: > On 2019-02-11, Felix Lazaro Carbonell wrote: > >> Could you please tell me wich way of writing this method is more >> pythonic: >> >> def find_monthly_expenses(month=None, year=None): >> month = month or datetime.da

Re: more pythonic way

, etc. > > > -Original Message- > From: Python-list [mailto:python-list-bounces+david.raymond= > tomtom@python.org] On Behalf Of Felix Lazaro Carbonell > Sent: Monday, February 11, 2019 2:30 PM > To: python-list@python.org > Subject: more pythonic way > &

Re: more pythonic way

On 2/11/2019 2:46 PM, Felix Lazaro Carbonell wrote: def find_monthly_expenses(month=None, year=None): month = month or datetime.date.today().month Or it should better be: if not month: month = datetime.date.today().month As a 20+ year veteran, I would

RE: more pythonic way

or overrides, etc. -Original Message- From: Python-list [mailto:python-list-bounces+david.raymond=tomtom@python.org] On Behalf Of Felix Lazaro Carbonell Sent: Monday, February 11, 2019 2:30 PM To: python-list@python.org Subject: more pythonic way Hello to everyone: Could you please tell me

RE: more pythonic way

-Mensaje original- De: Python-list [mailto:python-list-bounces+felix=epepm.cupet...@python.org] En nombre de Grant Edwards Enviado el: lunes, 11 de febrero de 2019 02:46 p.m. Para: python-list@python.org Asunto: Re: more pythonic way On 2019-02-11, Felix Lazaro Carbonell wrote

RE: more pythonic way

Sorry I meant .. def find_monthly_expenses(month=None, year=None): month = month or datetime.date.today().month .. Or it should better be: ... if not month: month = datetime.date.today().month .. Cheers, Felix. --

Re: more pythonic way

On 2019-02-11, Felix Lazaro Carbonell wrote: > Could you please tell me wich way of writing this method is more pythonic: > > def find_monthly_expenses(month=None, year=None): > month = month or datetime.date.today() > > Or it should better be: > &

more pythonic way

Hello to everyone: Could you please tell me wich way of writing this method is more pythonic: .. def find_monthly_expenses(month=None, year=None): month = month or datetime.date.today() .. Or it should better be: ... if not month: month

Re: Pythonic Y2K

On Fri, 18 Jan 2019, Gene Heskett wrote: I had one client, a hedge fund, that I fixed literally 1000's of Y2K issues for. When Y2K came and there were no problems, the owner said to me "You made such a big deal about the Y2K thing, and nothing happened." -- I would quite cheerfully have

Re: Pythonic Y2K

m, may need to start newer programs that use > the 3.X or beyond version as no back-ported version exists. The bubble > may enlarge and may eventually burst. > > -Original Message----- > From: Python-list > On Behalf Of > Larry Martell > Sent: Friday, January 18, 2019 10

Re: Pythonic Y2K

and communicate with them, may need to > start newer programs that use the 3.X or beyond version as no back-ported > version exists. The bubble may enlarge and may eventually burst. > > -Original Message- > From: Python-list On > Behalf Of Larry Martell > Sent:

RE: Pythonic Y2K

, 2019 10:47 AM To: Python Subject: Re: Pythonic Y2K On Fri, Jan 18, 2019 at 10:43 AM Michael Torrie wrote: > > On 01/16/2019 12:02 PM, Avi Gross wrote: > > I recall the days before the year 2000 with the Y2K scare when > > people worried that legacy software might

RE: Pythonic Y2K

nguage than the more modern python, fine. -Original Message- From: Python-list On Behalf Of Michael Torrie Sent: Friday, January 18, 2019 10:36 AM To: python-list@python.org Subject: Re: Pythonic Y2K On 01/16/2019 12:02 PM, Avi Gross wrote: > I recall the days before the year 200

Re: Pythonic Y2K

On 17/01/2019 02:34, Avi Gross wrote: but all it took was to set the clock forward on a test system and look for anomalies. You're new to programming or you're not very old and certainly haven't run much pre-Y2k software. ;-) Issues that needed solving: 2 digits only for the date use

Re: Pythonic Y2K

On 2019-01-18, Dennis Lee Bieber wrote: > Hey... I'm still waiting for a novelization of the TRS-DOS date "bug". > TRS-DOS directory structure only allocated 3-bits for the year. Three bits for the year? they didn't expect those computers to last long, eh? [My current Thinkpad is over

RE: Pythonic Y2K

Torrie Sent: Friday, January 18, 2019 10:36 AM To: python-list@python.org Subject: Re: Pythonic Y2K On 01/16/2019 12:02 PM, Avi Gross wrote: > I recall the days before the year 2000 with the Y2K scare when people > worried that legacy software might stop working or do horrible things once >

Re: Pythonic Y2K

On Fri, Jan 18, 2019 at 10:43 AM Michael Torrie wrote: > > On 01/16/2019 12:02 PM, Avi Gross wrote: > > I recall the days before the year 2000 with the Y2K scare when people > > worried that legacy software might stop working or do horrible things once > > the clock turned. It may even have been

Re: Pythonic Y2K

On 01/16/2019 12:02 PM, Avi Gross wrote: > I recall the days before the year 2000 with the Y2K scare when people > worried that legacy software might stop working or do horrible things once > the clock turned. It may even have been scary enough for some companies to > rewrite key applications and

RE: Pythonic Y2K

On Behalf Of Avi Gross Sent: Thursday, January 17, 2019 5:46 PM To: python-list@python.org Subject: RE: Pythonic Y2K Ian, You just scared me. It is 2019 which has four digits. In less than 8,000 years we will need to take the fifth to make numbers from 10,000 to 10,999. 90,000 years later we

Re: Pythonic Y2K

Back in the computer world, Y2K gave such managers some cover. There was a FIRM deadline. I wonder how many used the impending arrival of the year 2000 as an excuse to perhaps clean up other parts of their act and charge it to prevention. I mean they might suggest they rewrite some legacy COBOL

RE: Pythonic Y2K

in 2000 B.C. -Original Message- From: Python-list On Behalf Of Ian Kelly Sent: Thursday, January 17, 2019 2:14 PM To: Python Subject: Re: Pythonic Y2K On Wed, Jan 16, 2019 at 9:57 PM Avi Gross wrote: > > The forthcoming UNIX 2038 problem will, paradoxically happen on > Janu

RE: Pythonic Y2K

for 2020. -Original Message- From: Python-list On Behalf Of Schachner, Joseph Sent: Thursday, January 17, 2019 1:46 PM To: Python Subject: RE: Pythonic Y2K I'd like to add one more thing to your list of what companies will have to consider: 6) The ability to hire and retain employees who

Re: Pythonic Y2K

On Fri, Jan 18, 2019 at 8:47 AM DL Neil wrote: > > On 17/01/19 6:53 PM, Chris Angelico wrote: > > On Thu, Jan 17, 2019 at 3:55 PM Avi Gross wrote: > >> The forthcoming UNIX 2038 problem will, paradoxically happen on January 19. > >> > > > > Paradoxically? What do you mean by that? > > > First we

Re: Pythonic Y2K

On 17/01/19 6:53 PM, Chris Angelico wrote: On Thu, Jan 17, 2019 at 3:55 PM Avi Gross wrote: The forthcoming UNIX 2038 problem will, paradoxically happen on January 19. Paradoxically? What do you mean by that? First we had to duck the Y2K problem. By moving everything to 64-bits, we duck

  1   2   3   4   5   6   7   8   9   10   >