Re: dayofyear is not great when going into a new year

Den 2021-01-09 skrev Michael F. Stemper : > > A week is like a piece of string. It has two ends. > The control line of the main sheet traveler on my boat is spliced into an endless loop. http://hem.bredband.net/b262106/pages/controls/index.html I am glad work weeks are not like that :-) /Martin -

Re: dayofyear is not great when going into a new year

On Sun, Jan 10, 2021 at 1:31 AM Michael F. Stemper wrote: > > On 09/01/2021 01.51, Christian Gollwitzer wrote: > > Am 05.01.21 um 23:56 schrieb Eli the Bearded: > >> Elijah > >> -- > >> also finds "week starts on Monday" to be oddball about ISO-8601 > >> > > > > In Europe, the week starts on M

Re: dayofyear is not great when going into a new year

On 09/01/2021 01.51, Christian Gollwitzer wrote: Am 05.01.21 um 23:56 schrieb Eli the Bearded: Elijah -- also finds "week starts on Monday" to be oddball about ISO-8601 In Europe, the week starts on Monday - hence, Saturday and Sunday are the last days of the week or the "weekend". Start

Re: dayofyear is not great when going into a new year

Am 05.01.21 um 23:56 schrieb Eli the Bearded: Elijah -- also finds "week starts on Monday" to be oddball about ISO-8601 In Europe, the week starts on Monday - hence, Saturday and Sunday are the last days of the week or the "weekend". Starting on Sunday is weird for us, because then the w

Re: dayofyear is not great when going into a new year

On 9/01/21 11:17 am, Martin Schöön wrote: "regardless of what you have been told, recreational use of mathematics is harmless" I hope that is true for recreational programming as well :-) Mostly harmless, but it can be addictive! -- Greg -- https://mail.python.org/mailman/listinfo/python-list

Re: dayofyear is not great when going into a new year

Den 2021-01-05 skrev Stefan Ram : > Martin =?UTF-8?Q?Sch=C3=B6=C3=B6n?= writes: >>I have had some Python fun with COVID-19 data. I have done >>some curve fitting and to make that easier I have transformed >>date to day of year. Come end of 2020 and beginning of 2021 >>and this idea falls on its fa

Re: dayofyear is not great when going into a new year

On 1/5/21 8:02 PM, Mats Wichmann wrote: > On 1/5/21 4:04 PM, Chris Angelico wrote: >> On Wed, Jan 6, 2021 at 10:01 AM Eli the Bearded >> <*@eli.users.panix.com> wrote: >>> >>> In comp.lang.python, Chris Angelico  wrote: There are multiple definitions for "day of year", depending on how you >>

Re: dayofyear is not great when going into a new year

In comp.lang.python, Mats Wichmann wrote: > "workweeks" has always been fun, ISO standard or not, there's been a > variation for ages since people don't seem to always follow ISO for > that. I spent over a decade at a place that lived and died by their > WorkWeek references ("due WW22" or the

Re: dayofyear is not great when going into a new year

On 1/5/21 4:04 PM, Chris Angelico wrote: On Wed, Jan 6, 2021 at 10:01 AM Eli the Bearded <*@eli.users.panix.com> wrote: In comp.lang.python, Chris Angelico wrote: There are multiple definitions for "day of year", depending on how you want to handle certain oddities. The simplest is to identi

Re: dayofyear is not great when going into a new year

On Wed, Jan 6, 2021 at 10:01 AM Eli the Bearded <*@eli.users.panix.com> wrote: > > In comp.lang.python, Chris Angelico wrote: > > There are multiple definitions for "day of year", depending on how you > > want to handle certain oddities. The simplest is to identify Jan 1st > > as 1, Jan 2nd as 2,

Re: dayofyear is not great when going into a new year

In comp.lang.python, Chris Angelico wrote: > There are multiple definitions for "day of year", depending on how you > want to handle certain oddities. The simplest is to identify Jan 1st > as 1, Jan 2nd as 2, etc, to Dec 31st as either 365 or 366; but some > libraries will define the year as star

Re: dayofyear is not great when going into a new year

On Wed, Jan 6, 2021 at 9:51 AM Michael F. Stemper wrote: > > On 05/01/2021 15.27, Chris Angelico wrote: > > On Wed, Jan 6, 2021 at 8:02 AM Martin Schöön > > wrote: > > >> I have had some Python fun with COVID-19 data. I have done > >> some curve fitting and to make that easier I have transformed

Re: dayofyear is not great when going into a new year

On 05/01/2021 15.27, Chris Angelico wrote: On Wed, Jan 6, 2021 at 8:02 AM Martin Schöön wrote: I have had some Python fun with COVID-19 data. I have done some curve fitting and to make that easier I have transformed date to day of year. Come end of 2020 and beginning of 2021 and this idea fal

Re: dayofyear is not great when going into a new year

On 1/6/21 9:55 AM, Martin Schöön wrote: > Hello, > > I have had some Python fun with COVID-19 data. I have done > some curve fitting and to make that easier I have transformed > date to day of year. Come end of 2020 and beginning of 2021 > and this idea falls on its face. > > There must be a bett

Re: dayofyear is not great when going into a new year

On Wed, Jan 6, 2021 at 8:02 AM Martin Schöön wrote: > > Hello, > > I have had some Python fun with COVID-19 data. I have done > some curve fitting and to make that easier I have transformed > date to day of year. Come end of 2020 and beginning of 2021 > and this idea falls on its face. > There ar

dayofyear is not great when going into a new year

Hello, I have had some Python fun with COVID-19 data. I have done some curve fitting and to make that easier I have transformed date to day of year. Come end of 2020 and beginning of 2021 and this idea falls on its face. There must be a better way of doing this. I am using Pandas for reading and

Re: My appreciation for python's great work to my country.

Kiyimba, In my community in Arizona ( pop 7000) I am the only one using Linux and the only one who is studying Python, no one is coding. So spread your knowledge among the youth of your commun ity. It is good for their future. Alex Kaye On Sat, Feb 9, 2019 at 1:34 PM Terry Reedy wrote: > On 2

Re: My appreciation for python's great work to my country.

On 2/8/2019 4:37 AM, Kiyimba Godfrey wrote: I take this opportunity to thank python for having designed such a wonderful program which has enabled computer scientists and programmers in my country Uganda, understand, design and create other computer application programs . You're welcome, and

My appreciation for python's great work to my country.

I take this opportunity to thank python for having designed such a wonderful program which has enabled computer scientists and programmers in my country Uganda, understand, design and create other computer application programs . Yours, Lubega Tom Sent from Mail

Re: oldschool texter GUI with python, char repeating is not working great !

i just uploaded everything on github https://github.com/kourpetis/python_old_school_texter -- https://mail.python.org/mailman/listinfo/python-list

oldschool texter GUI with python, char repeating is not working great !

E'] sensor=[sensor01,sensor02,sensor03,sensor04, sensor05, sensor06, sensor07, sensor08, sensor09, sensor10, sensor11, sensor12, sensor13, sensor14, sensor15, sensor16] #the maximum number of times each sensor can be pressed #before it rols back to the first character. max_press=[1,1,1,1,2,5

Re: [OT] is JSON all that great? - was Re: API Help

On 16/06/17 12:03, alister wrote: (The non native English speaker excuse is not an option for me) Does that mean it's mandatory for you? I'm confused :D :D E. -- https://mail.python.org/mailman/listinfo/python-list

Re: [OT] is JSON all that great? - was Re: API Help

Grant Edwards writes: > On 2017-06-16, Ben Finney wrote: > > JSON is designed to be *a strictly limited subset* of legal > > JavaScript that only defines data structures. The explicit goal is > > that it is statically parseable as non-executable data. > > That doesn't mean that it's reasonable/a

Re: [OT] is JSON all that great? - was Re: API Help

On 2017-06-16, Ben Finney wrote: > alister writes: > >> Json is designed to be legal Javascript code & therefore directly >> executable so no parser is posible. > > JSON is designed to be *a strictly limited subset* of legal JavaScript > that only defines data structures. The explicit goal is tha

Re: [OT] is JSON all that great? - was Re: API Help

On Thu, 15 Jun 2017 21:17:05 +0100, Erik wrote: > On 15/06/17 15:10, Chris Angelico wrote: >> On Fri, Jun 16, 2017 at 12:00 AM, alister >> wrote: >>> Json is designed to be legal Javascript code & therefore directly >>> executable so no parser is posible. >>> >>> >> "no parser is possible"??? >

Re: [OT] is JSON all that great? - was Re: API Help

On Fri, 16 Jun 2017 00:10:58 +1000, Chris Angelico wrote: > On Fri, Jun 16, 2017 at 12:00 AM, alister > wrote: >> On Thu, 15 Jun 2017 22:27:40 +1000, Chris Angelico wrote: >> >>> On Thu, Jun 15, 2017 at 9:47 PM, Rhodri James >>> wrote: > 1) It is not secure. Check this out: > https://sta

Re: [OT] is JSON all that great? - was Re: API Help

alister writes: > Json is designed to be legal Javascript code & therefore directly > executable so no parser is posible. JSON is designed to be *a strictly limited subset* of legal JavaScript that only defines data structures. The explicit goal is that it is statically parseable as non-executab

Re: [OT] is JSON all that great? - was Re: API Help

On Fri, Jun 16, 2017 at 6:58 AM, Grant Edwards wrote: > On 2017-06-15, Erik wrote: >> On 15/06/17 15:10, Chris Angelico wrote: >>> On Fri, Jun 16, 2017 at 12:00 AM, alister wrote: Json is designed to be legal Javascript code & therefore directly executable so no parser is posible.

Re: [OT] is JSON all that great? - was Re: API Help

On Fri, Jun 16, 2017 at 6:17 AM, Erik wrote: > On 15/06/17 15:10, Chris Angelico wrote: >> >> On Fri, Jun 16, 2017 at 12:00 AM, alister >> wrote: >>> >>> Json is designed to be legal Javascript code & therefore directly >>> executable so no parser is posible. >>> >> >> "no parser is possible"???

Re: [OT] is JSON all that great? - was Re: API Help

On 2017-06-15, Erik wrote: > On 15/06/17 15:10, Chris Angelico wrote: >> On Fri, Jun 16, 2017 at 12:00 AM, alister wrote: >>> Json is designed to be legal Javascript code & therefore directly >>> executable so no parser is posible. >>> >> >> "no parser is possible"??? > > I *think* alister meant

Re: [OT] is JSON all that great? - was Re: API Help

On 15/06/17 15:10, Chris Angelico wrote: On Fri, Jun 16, 2017 at 12:00 AM, alister wrote: Json is designed to be legal Javascript code & therefore directly executable so no parser is posible. "no parser is possible"??? I *think* alister meant "so it is possible to not use a parser [librar

Re: [OT] is JSON all that great? - was Re: API Help

On Thursday 15 June 2017 01:10:26 Marko Rauhamaa wrote: > Chris Angelico : > > XML is thus poorly suited to *most* forms of data, > > Correct. > > > > > > > aa > > qq > > qw > > qe > > as > > > > > > What does this represent? A generic XML parser has to cope with it. > > I gave this t

Re: [OT] is JSON all that great? - was Re: API Help

On Fri, Jun 16, 2017 at 12:00 AM, alister wrote: > On Thu, 15 Jun 2017 22:27:40 +1000, Chris Angelico wrote: > >> On Thu, Jun 15, 2017 at 9:47 PM, Rhodri James >> wrote: 1) It is not secure. Check this out: https://stackoverflow.com/questions/1906927/xml- > vulnerabilities#1907500 >>> X

Re: [OT] is JSON all that great? - was Re: API Help

On Thu, 15 Jun 2017 22:27:40 +1000, Chris Angelico wrote: > On Thu, Jun 15, 2017 at 9:47 PM, Rhodri James > wrote: >>> 1) It is not secure. Check this out: >>> https://stackoverflow.com/questions/1906927/xml- vulnerabilities#1907500 >> XML and JSON share the vulnerabilities that come from having

Re: [OT] is JSON all that great? - was Re: API Help

On Thu, Jun 15, 2017 at 9:47 PM, Rhodri James wrote: >> 1) It is not secure. Check this out: >> https://stackoverflow.com/questions/1906927/xml-vulnerabilities#1907500 > XML and JSON share the vulnerabilities that come from having to parse > untrusted external input. XML then has some extra since

Re: [OT] is JSON all that great? - was Re: API Help

People seem to be having fun bashing XML, so I thought I'd wade in on its behalf. On 15/06/17 03:46, justin walters wrote: There are 2 main issues with XML: 1) It is not secure. Check this out: https://stackoverflow.com/questions/1906927/xml-vulnerabilities#1907500 XML and JSON share the vul

Re: [OT] is JSON all that great? - was Re: API Help

Michael Torrie wrote: I don't find JSON any more human readable than XML to be honest, perhaps less so because there's no way to define a formal schema to follow, at least that I'm aware of. You mean like this? http://json-schema.org/ One thing I like better about JSON than XML as a serialisa

Re: [OT] is JSON all that great? - was Re: API Help

Chris Angelico : > XML is thus poorly suited to *most* forms of data, Correct. > > > aa > qq > qw > qe > as > > > What does this represent? A generic XML parser has to cope with it. I > gave this to a few XML-to-JSON converters, and they all interpreted it > as some variant of {"asd

Re: [OT] is JSON all that great? - was Re: API Help

On Thu, Jun 15, 2017 at 12:33 PM, Michael Torrie wrote: > To me JSON seems to hold no real benefits over other serialization > techniques, including the XML beast. XML may be verbose, but at least > XML data can be formally validated and formally transformed and queried, > which is certainly not t

Re: [OT] is JSON all that great? - was Re: API Help

On Wed, Jun 14, 2017 at 7:33 PM, Michael Torrie wrote: > On 06/14/2017 05:06 PM, justin walters wrote: > > JSON in Python is such a joy! :) > > I understand that in this case the data is coming from a server in a > form intended for easy use with Javascript. But other than this type of > communi

Re: [OT] is JSON all that great? - was Re: API Help

On 2017-06-15, Michael Torrie wrote: > On 06/14/2017 05:06 PM, justin walters wrote: >> JSON in Python is such a joy! :) 100% agreement here. > I understand that in this case the data is coming from a server in a > form intended for easy use with Javascript. But other than this > type of commun

Re: [OT] is JSON all that great? - was Re: API Help

On Wed, Jun 14, 2017 at 9:33 PM, Michael Torrie wrote: > To me JSON seems to hold no real benefits over other serialization > techniques, including the XML beast. I guess we'll have to agree to disagree. XML is the Devil's spawn, hiding its real intent inside layer after layer of tags. In contras

[OT] is JSON all that great? - was Re: API Help

On 06/14/2017 05:06 PM, justin walters wrote: > JSON in Python is such a joy! :) I understand that in this case the data is coming from a server in a form intended for easy use with Javascript. But other than this type of communication, I don't see any good reason to choose JSON as a data interch

Re: I want to learn Python and how to benefit from the great Data Science packages - have some questions.

On Sunday, May 7, 2017 at 1:03:57 AM UTC+5:30, Rahim Shamsy wrote: > Hi, > > Hope you are well. I am currently in the process of learning the basics of > programming in Python, and was just checking if I am in the right direction. The tutorial https://docs.python.org/3/tutorial/ is short and g

Re: I want to learn Python and how to benefit from the great Data Science packages - have some questions.

On Mon, May 8, 2017 at 2:34 AM, Dennis Lee Bieber wrote: > I can partly agree with one aspect... In comparison to my old life > with > versions of FORTRAN, wherein standards were roughly 10 years apart, each > standard tended to accept all of a previous standard, while declaring > things

Re: I want to learn Python and how to benefit from the great Data Science packages - have some questions.

On Sunday, May 7, 2017 at 8:21:01 AM UTC+1, Shivangi Motwani wrote: > Hey! > > Learn Python The Hard Way is good I cannot recommend LPTHW after the author had this https://learnpythonthehardway.org/book/nopython3.html to say late last year. The best of the rebuttals is here https://eev.ee/blo

Re: I want to learn Python and how to benefit from the great Data Science packages - have some questions.

On Saturday, May 6, 2017 at 8:33:57 PM UTC+1, Rahim Shamsy wrote: > Hi, > > Hope you are well. I am currently in the process of learning the basics of > programming in Python, and was just checking if I am in the right direction. > I have experience programming in C++ and Java, and want to lear

Re: I want to learn Python and how to benefit from the great Data Science packages - have some questions.

Hey! Learn Python The Hard Way is good, apart from that you can take Udacitie's Intro to Data Analysis: https://in.udacity.com/course/intro-to-data-analysis--ud170/ This will help you learn numpy and pandas which will be very useful. Hope that helps! On Sun, May 7, 2017 at 1:03 AM, Rahim Shamsy

Re: I want to learn Python and how to benefit from the great Data Science packages - have some questions.

On 05/06/2017 01:33 PM, Rahim Shamsy wrote: > Is there a better and faster way? I need more problem solving > experience (keeping in mind Data Science) with python. Probably. Depends on the person and how one learns. The best way to learn python is to have a problem you wish to solve and start co

I want to learn Python and how to benefit from the great Data Science packages - have some questions.

Hi, Hope you are well. I am currently in the process of learning the basics of programming in Python, and was just checking if I am in the right direction. I have experience programming in C++ and Java, and want to learn Python for research work that I am doing. The research is regarding appli

Re: Were is a great place to Share your finished projects?

Marko Rauhamaa : > Anyway, all of this has reminded me that bitkeeper is now free. I've > never tried it so let's see if it is everything Sun's Teamware was. Hm, ran into compilation trouble. Maybe I should wait till bk is available for Fedora. Marko -- https://mail.python.org/mailman/listinfo

Re: Were is a great place to Share your finished projects?

Chris Angelico : > I've never managed to get Mercurial's branching system into my head > (and then you have the people saying "don't use hg branches at all, > just use named tags" or somesuch), but the git branching system is > extremely simple. In fact, all of git is very simple. To anyone who is

Re: Were is a great place to Share your finished projects?

On Sat, Jul 16, 2016 at 1:39 AM, Brandon McCaig wrote: > [regarding Mercurial] > Combined with their failure to accomodate the distributed > development model properly you now have a bunch of incompatible > ideas for managing branches and history editing and they still > haven't gotten it all righ

Re: Were is a great place to Share your finished projects?

On Fri, Jul 15, 2016 at 10:39:05AM +1000, Steven D'Aprano wrote: > About seven years ago, the senior technical manager at my work chose hg over > git. When he left to go to greener pastures, the dev team took about 30 > seconds to to reverse his decision and migrate to git, after which the > level

Re: Were is a great place to Share your finished projects?

Steven D'Aprano writes: > On Fri, 15 Jul 2016 09:13 am, Brendan Abel wrote: > > since they all use software that is closed-source.  At some point, > > paying for software just makes sense. Is it 1998 again already? Or am I expecting too much that people involved in software in the 21st century

Re: Were is a great place to Share your finished projects?

On Fri, 15 Jul 2016 09:13 am, Brendan Abel wrote: > In the article he makes a good point that if > you're that worried about always using open-source, then you shouldn't be > using gmail, or twitter, or even automobiles, It's not a good point. I don't use gmail, or twitter, and if I could find a

Re: Were is a great place to Share your finished projects?

On Fri, 15 Jul 2016 09:04 am, Lawrence D’Oliveiro wrote: > On Friday, July 15, 2016 at 7:04:14 AM UTC+12, hasan...@gmail.com wrote: > >> ... I see nothing git offers over mercurial. > > Except greater productivity. That has not been even close to my experience. And I don't mean my *personal* ex

Re: Were is a great place to Share your finished projects?

A lot of these arguments and points have already been made and hashed out on the python-dev list. There's a very good article that one of the python core developers wrote about the decision to move to github http://www.snarky.ca/the-history-behind-the-decision-to-move-python-to-github Basically,

Re: Were is a great place to Share your finished projects?

On Friday, July 15, 2016 at 7:04:14 AM UTC+12, hasan...@gmail.com wrote: > ... I see nothing git offers over mercurial. Except greater productivity. -- https://mail.python.org/mailman/listinfo/python-list

Re: Were is a great place to Share your finished projects?

On 7/14/2016 3:04 PM, hasan.di...@gmail.com wrote: Python's primary repository is Mercurial (hg.python.org), not Git. CPython's current repository Ditto for the PSF Python docs. Were python to switch, Like it or not, CPython and the Docs are moving to git and github. PEPs and the devg

Re: Were is a great place to Share your finished projects?

Michael Torrie writes: >I understand that in Python's case, pure cost wins out. Python.org >could host a GitLab instance, which contains the repo tools plus ticket >tracking, etc, and ordinary developers could push their changes to their >own public git repos and send in pull requests and it wou

Re: Were is a great place to Share your finished projects?

Michael Torrie writes: > So I can understand the allure of GitHub. It's shiny and free-ish. Savannah.nongnu.org is a nice free host for free software projects. I suppose it's less shiny than Github. On the other hand, Github is written in Ruby--what self-respecting Pythonista would stand for t

Re: Were is a great place to Share your finished projects?

On 07/13/2016 01:00 AM, Chris Angelico wrote: > On Wed, Jul 13, 2016 at 4:44 PM, Steven D'Aprano > wrote: >> Even if Github was 100% open source with no proprietary extensions, and the >> *technical* cost of leaving was low, the single-network effect would still >> lock >> you in, which leaves yo

Re: Were is a great place to Share your finished projects?

On Thursday, July 14, 2016 at 1:03:30 AM UTC+12, Rustom Mody wrote: > > Note further that Torvalds was told off by prof. Tanenbaum for his poor > quality unimaginative approach to Linux And today, Prof Tanenbaum is struggling to find a little niche where his Minix product can be of relevance, whi

Re: Were is a great place to Share your finished projects?

On Wednesday, July 13, 2016 at 10:42:01 AM UTC+5:30, Chris Angelico wrote: > On Wed, Jul 13, 2016 at 2:42 PM, Ben Finney wrote: > > Chris Angelico writes: > > > >> On Wed, Jul 13, 2016 at 11:28 AM, Ben Finney wrote: > >> > Pull requests. Code review. Issues. Integration with other services. > >>

Re: Were is a great place to Share your finished projects?

On Wed, Jul 13, 2016 at 6:49 PM, Steven D'Aprano wrote: >> what >> are you going to do, move your project to some backwater VCS where nobody >> ever goes? > > "...some backwater where nobody ever goes..." > > If you really mean that, then you're saying that Github has already captured > such a dom

Re: Were is a great place to Share your finished projects?

On Wednesday 13 July 2016 17:00, Chris Angelico wrote: > On Wed, Jul 13, 2016 at 4:44 PM, Steven D'Aprano > wrote: >> Even if Github was 100% open source with no proprietary extensions, and the >> *technical* cost of leaving was low, the single-network effect would still >> lock you in, which lea

Re: Were is a great place to Share your finished projects?

On Wed, Jul 13, 2016 at 4:44 PM, Steven D'Aprano wrote: > Even if Github was 100% open source with no proprietary extensions, and the > *technical* cost of leaving was low, the single-network effect would still > lock > you in, which leaves you (to some degree) at the mercy of Github's management

Re: Were is a great place to Share your finished projects?

risks excessively. There are people who plan and plant great gardens which they will never see completed, trees taking many decades to reach maturity. And there are those who think that doing the washing on the weekend so they'll have clothes to wear on Tuesday counts as "long term plan

Re: Were is a great place to Share your finished projects?

On Wed, Jul 13, 2016 at 2:42 PM, Ben Finney wrote: > Chris Angelico writes: > >> On Wed, Jul 13, 2016 at 11:28 AM, Ben Finney >> wrote: >> > Pull requests. Code review. Issues. Integration with other services. >> > All the social information around all of those interactions, and >> > more. >> >

Re: Were is a great place to Share your finished projects?

Chris Angelico writes: > On Wed, Jul 13, 2016 at 11:28 AM, Ben Finney > wrote: > > Pull requests. Code review. Issues. Integration with other services. > > All the social information around all of those interactions, and > > more. > > > > If *any* of that is valuable, then yes it's important th

Re: Were is a great place to Share your finished projects?

On Wed, Jul 13, 2016 at 11:28 AM, Ben Finney wrote: > Pull requests. Code review. Issues. Integration with other services. All > the social information around all of those interactions, and more. > > If *any* of that is valuable, then yes it's important that it not be > locked to any one vendor.

Re: Were is a great place to Share your finished projects?

Christian Gollwitzer writes: > Am 01.07.16 um 03:38 schrieb Ben Finney: > > If one wants to avoid vendor lock-in, Github is not best: the > > workflow tools (other than Git itself) are completely closed and not > > available for implementation on another vendor's servers. > > Yes, but that is rel

Re: Namespaces are one honking great idea

Hi all, although it doesn't fit the bill 100%, I sometimes use this extremely simple function as a decorator: def new(call): return call() For example: @new class MySingleton: x = 2 y = 2 def sum(self, x, y): return x + y @new def my_obj(): x = 2 y = 2 de

A nestedmodule decorator (Re: Namespaces are one honking great idea)

Steven D'Aprano wrote: There's only so far I can go without support from the compiler. It turns out one can go surprisingly far. Here's something I cooked up that seems to meet almost all the requirements. The only shortcoming I can think of is that a nestedmodule inside another nestedmodule wo

Re: Namespaces are one honking great idea

On Tuesday 05 July 2016 13:47, Chris Angelico wrote: > On Tue, Jul 5, 2016 at 1:35 PM, Steven D'Aprano wrote: >>> If you push your code into a separate .py file, you can reference the >>> original module by importing it. Is that also the normal way to use >>> "outer" functions etc from inside a n

Re: Namespaces are one honking great idea

On Tue, Jul 5, 2016 at 1:35 PM, Steven D'Aprano wrote: >> If you push your code into a separate .py file, you can reference the >> original module by importing it. Is that also the normal way to use >> "outer" functions etc from inside a namespace? > > Good question! > > With the current implement

Re: Namespaces are one honking great idea

On Tue, 5 Jul 2016 12:58 pm, Chris Angelico wrote: > On Tue, Jul 5, 2016 at 12:34 PM, Steven D'Aprano > wrote: >> *** IF *** you are willing to push the code out into its own separate .py >> file, you can use a module and write your code in a more natural form: >> >> >> # module example.py >> var

Re: Namespaces are one honking great idea

On Tue, Jul 5, 2016 at 12:34 PM, Steven D'Aprano wrote: > *** IF *** you are willing to push the code out into its own separate .py > file, you can use a module and write your code in a more natural form: > > > # module example.py > var = 999 > > def spam(arg): > return eggs(arg) + var > > def

Re: Namespaces are one honking great idea

On Mon, 4 Jul 2016 09:23 pm, jmp wrote: > On 07/01/2016 04:13 PM, Steven D'Aprano wrote: >> But classes are not like the others: they must be instantiated before >> they can be used, and they are more than just a mere namespace grouping >> related entities. Classes support inheritance. Classes sho

Re: Namespaces are one honking great idea

On Tuesday, July 5, 2016 at 10:10:04 AM UTC+12, I wrote: > > On Monday, July 4, 2016 at 11:37:44 PM UTC+12, Chris Angelico wrote: > > > Functions within the namespace can't call other functions within the > > same namespace using unqualified names. This was a stated requirement. > > Doesn’t my @n

Re: Namespaces are one honking great idea

On Monday, July 4, 2016 at 11:37:44 PM UTC+12, Chris Angelico wrote: > Functions within the namespace can't call other functions within the > same namespace using unqualified names. This was a stated requirement. Doesn’t my @namespace decorator provide that? -- https://mail.python.org/mailman/li

Re: Namespaces are one honking great idea

On 07/04/2016 01:37 PM, Chris Angelico wrote: On Mon, Jul 4, 2016 at 9:23 PM, jmp wrote: On 07/01/2016 04:13 PM, Steven D'Aprano wrote: But classes are not like the others: they must be instantiated before they can be used, and they are more than just a mere namespace grouping related entitie

Re: Namespaces are one honking great idea

On Mon, Jul 4, 2016 at 9:23 PM, jmp wrote: > On 07/01/2016 04:13 PM, Steven D'Aprano wrote: >> >> But classes are not like the others: they must be instantiated before they >> can be used, and they are more than just a mere namespace grouping related >> entities. Classes support inheritance. Class

Re: Namespaces are one honking great idea

On 07/01/2016 04:13 PM, Steven D'Aprano wrote: But classes are not like the others: they must be instantiated before they can be used, and they are more than just a mere namespace grouping related entities. Classes support inheritance. Classes should be used for "is-a" relationships, not "has-a"

Re: Namespaces are one honking great idea

On 07/03/2016 03:02 PM, Kevin Conway wrote: >At some point earlier Ethan Furman declared: It's not a language change. Perhaps. My argument is that anything that introduces a new class-like construct and set of lexical scoping rules is a language change. For example, if this change went into 2.

Re: Namespaces are one honking great idea

On 04/07/2016 00:21, Lawrence D’Oliveiro wrote: On Monday, July 4, 2016 at 10:02:59 AM UTC+12, Kevin Conway wrote: If the problem with using classes to satisfy the namespace need is that it's unwieldy to use dot qualified paths then isn't that quite similar to saying namespaces are unwieldy? P

Re: Namespaces are one honking great idea

On Monday, July 4, 2016 at 10:02:59 AM UTC+12, Kevin Conway wrote: > If the problem with using classes to satisfy the namespace need is > that it's unwieldy to use dot qualified paths then isn't that quite similar > to saying namespaces are unwieldy? Python has a simple solution to that: a =

Re: Namespaces are one honking great idea

>> Regardless, all use cases you've listed are already satisfied by use of >> the static and class method decorators. Methods decorated with these do >> not require an instance initialization to use. > And are significantly less easy to use, as the functions MUST refer to each > other by their dot

Re: Namespaces are one honking great idea

On 07/02/2016 08:44 PM, Steven D'Aprano wrote: Try getting this behaviour from within a class: class Food(metaclass=Namespace): # (1) no special decorators required def spam(n): return ' '.join(['spam']*n) # (2) can call functions from inside the namespace breakf

Re: Namespaces are one honking great idea

On Sun, 3 Jul 2016 01:34 am, Kevin Conway wrote: > staticmethod isn't technically required to use a method through the class > (or subclasses), it simply provides the appropriate magic to allow it to > be called through instances. > > For example, the following code covers all described use cases

Re: Namespaces are one honking great idea

ce But classes provide much more functionality, over and above mere namespace: inheritance, instantiation, etc. I'm not anti-classes or opposed to OOP, these features are great when they are wanted. But when they aren't wanted, they're a nuisance. Modules also provide more than just an ab

Re: Namespaces are one honking great idea

On 07/02/2016 08:34 AM, Kevin Conway wrote: For the proponents of namespace, what is deficient in the above example that necessitates a language change? Adding a new widget is not changing the language. -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list

Re: Namespaces are one honking great idea

> staticmethod isn't technically required to use a method through the class (or subclasses), it simply provides the appropriate magic to allow it to be called through instances. For example, the following code covers all described use cases of the proposed namespace. Methods are invoked without cr

Re: Namespaces are one honking great idea

On Fri, Jul 1, 2016, at 21:50, Kevin Conway wrote: > I believe the namespace object you are referring to is exactly a > class. IIRC, classes came about as a "module in a module". No, because classes have instances. And conceptually they seem like they *should* have instances. Just using the term "

Re: Namespaces are one honking great idea

On Saturday, July 2, 2016 at 1:50:56 PM UTC+12, Kevin Conway wrote: > Regardless, all use cases you've listed are already satisfied by use of the > static and class method decorators. Except for the need to decorate every such function inside the class. How about: import types def namesp

Re: Namespaces are one honking great idea

On Friday, July 1, 2016 at 8:19:36 PM UTC+5:30, BartC wrote: > On 01/07/2016 15:13, Steven D'Aprano wrote: > > > Sometimes we have a group of related functions and variables that belong > > together, but are not sufficiently unrelated to the rest of the module that > > we want to split them out in

Re: Namespaces are one honking great idea

I believe the namespace object you are referring to is exactly a class. IIRC, classes came about as a "module in a module". Regardless, all use cases you've listed are already satisfied by use of the static and class method decorators. Methods decorated with these do not require an instance initia

Re: Namespaces are one honking great idea

On Sat, 2 Jul 2016 05:29 am, Ethan Furman wrote: > On 07/01/2016 10:10 AM, Steven D'Aprano wrote: >> On Sat, 2 Jul 2016 02:00 am, Ethan Furman wrote: > >>> Did you mean for this to go to -Ideas? >> >> Not yet. I wanted some initial feedback to see if anyone else liked the >> idea before taking it

Re: Namespaces are one honking great idea

On 07/01/2016 10:10 AM, Steven D'Aprano wrote: On Sat, 2 Jul 2016 02:00 am, Ethan Furman wrote: Did you mean for this to go to -Ideas? Not yet. I wanted some initial feedback to see if anyone else liked the idea before taking it to Bikeshedding Central :-) Besides, I expect Python-Ideas wil

  1   2   3   4   5   >