>>> 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
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
sts or use
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 trut
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 t
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
nd 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 some people will still typically add
"
> 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 &qu
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 a
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 libra
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 sp
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
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
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" an
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
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
out 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 optio
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 situa
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
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 t
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* b
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'
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 ther
from 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
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.
>
No specific requirement. These are *finger exercises* intended to isolate
one issue for discussion rather than be useful in themselves.
>
27;t *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 th
n val0
else:
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
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
>
#x27;ve written 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
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 al
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
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
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 m
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 something
> obvious!
sn'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!
l 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!
Thanks,
-s
def firsta(iterable):
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)
>
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 happen?
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 for
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 c
sp
> 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
--
Luci
> 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 a
nverting 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
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.
--
https://mail.pytho
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
>
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 modi
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
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
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:
foo.delete(
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 have
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 upstream
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
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 synta
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, and
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 *mi
is a hyperthin wrapper
around the requests 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 mor
t;
> OK, I'll bite...
>
> ...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 l
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:
api_label/intro/ID.what_we're_going_to_do.who/what_we'
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, supp
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)
ap
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 expect
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)
api.customers_u
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):
>>>
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 is calculate
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
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:
>
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.date.
tations 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 py
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 be
lementations 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
-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
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.
--
https://mail.python.org/mailman
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:
>
&
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
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 bough
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
r scripts 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
, 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
a DIFFERENT language 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 th
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
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 10
f
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 2000 with the Y2K scare when people
> worried that legacy software might stop working or do horrible things
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 s
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 e
g] 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
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 or
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
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
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
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 t
On 2019-01-17, Schachner, Joseph wrote:
> 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 will be happy to
>program in an obsolete version of Python. A version about which
>new books will probably
On Wed, Jan 16, 2019 at 9:57 PM Avi Gross wrote:
>
> The forthcoming UNIX 2038 problem will, paradoxically happen on January
19. I wonder what they will do long before then. Will they just add a byte
or four or 256 and then make a date measurable in picoseconds? Or will they
start using a number f
On Fri, Jan 18, 2019 at 5:48 AM Schachner, Joseph
wrote:
>
> 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 will be happy to program in
> an obsolete version of Python. A version about which new books wi
From: Chris Angelico
Sent: Wednesday, January 16, 2019 2:15 PM
To: Python
Subject: Re: Pythonic Y2K
On Thu, Jan 17, 2019 at 6:04 AM Avi Gross wrote:
>
> I see messages like the following where someone is still asking how to
> do something in some version of python 2.X.
>
> I recall
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?
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
al Message-
From: Python-list On
Behalf Of DL Neil
Sent: Wednesday, January 16, 2019 11:04 PM
To: Python
Subject: Re: Pythonic Y2K
On 17/01/19 4:45 PM, Larry Martell wrote:
> On Wed, Jan 16, 2019 at 9:35 PM Avi Gross wrote:
>>
>> Chris,
>>
>> The comparison to Y2K
I can well understand people
holding on to what they know, especially when the new stuff is likely to keep
changing. Some of that legacy code probably is very un-pythonic and a
relatively minimal translation from how it was done in C, when that is
possible. Arguably such code might be easier to
On 17/01/19 4:45 PM, Larry Martell wrote:
On Wed, Jan 16, 2019 at 9:35 PM Avi Gross wrote:
Chris,
The comparison to Y2K was not a great one. I am not sure what people did in
advance, but all it took was to set the clock forward on a test system and
look for anomalies. Not everything would be
On Wed, Jan 16, 2019 at 9:35 PM Avi Gross wrote:
>
> Chris,
>
> The comparison to Y2K was not a great one. I am not sure what people did in
> advance, but all it took was to set the clock forward on a test system and
> look for anomalies. Not everything would be found but it gave some hints.
Clea
January 16, 2019 2:15 PM
To: Python
Subject: Re: Pythonic Y2K
On Thu, Jan 17, 2019 at 6:04 AM Avi Gross wrote:
>
> I see messages like the following where someone is still asking how to
> do something in some version of python 2.X.
>
> I recall the days before the year 2000 with the
On Thu, Jan 17, 2019 at 6:04 AM Avi Gross wrote:
>
> I see messages like the following where someone is still asking how to do
> something in some version of python 2.X.
>
> I recall the days before the year 2000 with the Y2K scare when people
> worried that legacy software might stop working or d
1 - 100 of 1424 matches
Mail list logo
