[Python-ideas] Re: How to propose a change with tests where the failing test case (current behaviour) is bad or dangerous
On 05/27/2020 05:53 PM, Rob Cliffe via Python-ideas wrote: No, I downloaded a 3rd-party package. I'm not sure if that's "specialist sotware" by your definition. I won't name it here, but it was dead easy to install and use and works perfectly. Personally I'd recommend it. You'd recommend it, but you won't name it? Hmmm. ;) -- ~Ethan~ ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/N3I46EFGAML3SHXRNK5IDIBTYVE65BY6/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Optional keyword arguments
On Thu, May 28, 2020 at 10:42 AM Rob Cliffe wrote: > > > > On 26/05/2020 20:03, Chris Angelico wrote: > > On Wed, May 27, 2020 at 2:51 AM Steven D'Aprano wrote: > >> But doing otherwise, having Undef be *not an object* but a kinda ghost > >> in the interpreter, is a huge language change and I doubt it would be > >> worth it. > >> > > But is it a huge change? I thought so too, until Greg suggested a > > quite plausible option: leave the local unbound. There'd be two > > changes needed, and one of them could have other value. The semantics > > would be exactly the same as any other unbound local. > > > > def foo(): > > if False: x = 0 > > # what is x now? > > > > There is no *value* in x, yet x has a state. > > [snip] > Sorry, I don't think it does. It's not in locals(), it doesn't exist > anywhere in memory. > It might be created later in foo(), but it would then have a value. It is in the state of being unbound, and you can prove this by attempting to print it out. >>> foo() Traceback (most recent call last): File "", line 1, in File "", line 3, in foo UnboundLocalError: local variable 'x' referenced before assignment This is NOT the same as if the assignment hadn't been in the code (which would have gone looking for a global or builtin x). So yes, it does have a state. ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/CN3OPIQO4FOIDUADC7TW6RKBY57UKD6U/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: How to propose a change with tests where the failing test case (current behaviour) is bad or dangerous
On 25/05/2020 15:33, Steven D'Aprano wrote: On Fri, May 22, 2020 at 03:54:30PM +0100, Rob Cliffe via Python-ideas wrote: I find having a RAM drive is very handy. Could this be another use for it? Could be, if there's a standard way to create a RAM drive on all windows machines without needing to install specialist RAM drive software from a third party. No, I downloaded a 3rd-party package. I'm not sure if that's "specialist sotware" by your definition. I won't name it here, but it was dead easy to install and use and works perfectly. Personally I'd recommend it. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/VIRJXQBIBGSNVVFN5LNCWOMMHXVX4TOS/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Optional keyword arguments
APOLOGY: My e-mail client (Thunderbird) crashed as I hit Send; I don't know if it was actually sent. Therefore I am sending it again - sorry if it's a duplicate post. Rob Cliffe On 26/05/2020 20:03, Chris Angelico wrote: On Wed, May 27, 2020 at 2:51 AM Steven D'Aprano wrote: But doing otherwise, having Undef be *not an object* but a kinda ghost in the interpreter, is a huge language change and I doubt it would be worth it. But is it a huge change? I thought so too, until Greg suggested a quite plausible option: leave the local unbound. There'd be two changes needed, and one of them could have other value. The semantics would be exactly the same as any other unbound local. def foo(): if False: x = 0 # what is x now? There is no *value* in x, yet x has a state. [snip] Sorry, I don't think it does. It's not in locals(), it doesn't exist anywhere in memory. It might be created later in foo(), but it would then have a value. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/FWIL5IVXJJYHOCZKWDLT7XYJBYZAIHR6/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Optional keyword arguments
On 26/05/2020 05:03, David Mertz wrote: On Mon, May 25, 2020, 11:56 PM Christopher Barker well, yes and no. this conversation was in the context of "None" works fine most of the time. How many functions take None as a non-sentinel value?! How many of that tiny numbers do so only because they are poorly designed. None already is an excellent sentinel. We really don't need others. In the rare case where we really need to distinguish None from "some other sentinel" we should create our own special one. The only functions I can think of where None is appropriately non-sentinel are print(), id(), type(), and maybe a couple other oddball special ones. Seriously, can you name a function from the standard library or another popular library where None doesn't have a sentinel role as a function argument (default or not)? str(), repr(), ascii(). bool(), callable(), dir(), format(), hash(), help(), isinstance(None, ...) ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/HRHERKG7LQABU6C3CCQ4ASRAX4NLRTAP/ Code of Conduct: http://python.org/psf/codeofconduct/ ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/BLFXFVKW7H7S32IISHYL33KRKSAKDJ2N/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: An HTTP API to list versions of Python
The downside to the FTP solution however is that little metadata is present about the versions The FTP pages are primarily for downloading versions which isn't the aim of the proposal, it's to be able to fetch the metadata. Adding some sort of metadata file to all versions on the FTP server would solve the problem but at that point I'm not sure the "doesn't need any new process" argument still holds water. On Wed, 27 May 2020 at 22:36, M.-A. Lemburg wrote: > On 27.05.2020 18:59, Antoine Pitrou wrote: > > On Tue, 26 May 2020 22:19:12 -0400 > > Kyle Stanley wrote: > >> > >>> It could become more detailed about each minor versions, git tag, > links > >> to changelogs, links to the repositories, to the docs, download links, > >> and so on. > >> > >> I don't know that it needs to be said, but for now, I think we should > start > >> with a minimalist approach by keeping the API focused on reducing the > >> number of *existing* locations to update, rather than predicting what > might > >> sort of fields might be useful to include. Otherwise, it could very well > >> end up becoming more work to maintain compared to what it actually > saves. > > > > Unless unusual fields are required in the returned information, how > > about using PyPI as the information store? That way, you don't have to > > design a new API and implement a new backend... > > > > (that doesn't mean PyPI needs to host any downloadable files for Pyhon, > > by the way - just the metadata) > > Here's something which is close to an HTTP API and doesn't need any new > process, since it's been working for ages... > > https://www.python.org/ftp/python/ > > (and it's also easier to use than the regular python.org download > mechanisms) > > If you're looking for the 1.x releases, you can find them here: > > https://www.python.org/ftp/python/src/ > > Even earlier ones are on USENET. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Experts (#1, May 27 2020) > >>> Python Projects, Coaching and Support ...https://www.egenix.com/ > >>> Python Product Development ...https://consulting.egenix.com/ > > > ::: We implement business ideas - efficiently in both time and costs ::: > >eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 > D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg >Registered at Amtsgericht Duesseldorf: HRB 46611 >https://www.egenix.com/company/contact/ > https://www.malemburg.com/ > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/XMURTTG67FWUZVQCXCQWHTGZTX7YYDGF/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/OETITTXYD4NAJ3IQRPPQRSCZNJNFANNR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: An HTTP API to list versions of Python
On 27.05.2020 18:59, Antoine Pitrou wrote: > On Tue, 26 May 2020 22:19:12 -0400 > Kyle Stanley wrote: >> >>> It could become more detailed about each minor versions, git tag, links >> to changelogs, links to the repositories, to the docs, download links, >> and so on. >> >> I don't know that it needs to be said, but for now, I think we should start >> with a minimalist approach by keeping the API focused on reducing the >> number of *existing* locations to update, rather than predicting what might >> sort of fields might be useful to include. Otherwise, it could very well >> end up becoming more work to maintain compared to what it actually saves. > > Unless unusual fields are required in the returned information, how > about using PyPI as the information store? That way, you don't have to > design a new API and implement a new backend... > > (that doesn't mean PyPI needs to host any downloadable files for Pyhon, > by the way - just the metadata) Here's something which is close to an HTTP API and doesn't need any new process, since it's been working for ages... https://www.python.org/ftp/python/ (and it's also easier to use than the regular python.org download mechanisms) If you're looking for the 1.x releases, you can find them here: https://www.python.org/ftp/python/src/ Even earlier ones are on USENET. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, May 27 2020) >>> Python Projects, Coaching and Support ...https://www.egenix.com/ >>> Python Product Development ...https://consulting.egenix.com/ ::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 https://www.egenix.com/company/contact/ https://www.malemburg.com/ ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/XMURTTG67FWUZVQCXCQWHTGZTX7YYDGF/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Python JIT Compilation Thoughts
On Wed, 27 May 2020 21:24:08 +0300 Paul Sokolovsky wrote: > Hello, > > On Wed, 27 May 2020 08:18:11 - > redrad...@gmail.com wrote: > > > Thanks Guido !! > > > > I have not known about `pyston` ... It is pretty good like for me > > I will take a close look at this project > > A recent attempt to collect known Python JITs/compilers: > https://github.com/pfalcon/awesome-python-compilers (well, definitely > more recent than > https://wiki.python.org/moin/PythonImplementations#Compilers). And > even that is not complete, I'm still too lazy to add mypyc there, as > hopefully everyone knows about it anyway. I'm quite sure that not everyone knows about mypyc... far from it. But mypyc doesn't seem to be a JIT compiler anyway. Regards Antoine. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/PQS6ZTKKBRO6JAVPEYJHFCDHDIHSFJIW/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Python JIT Compilation Thoughts
Hello, On Wed, 27 May 2020 08:18:11 - redrad...@gmail.com wrote: > Thanks Guido !! > > I have not known about `pyston` ... It is pretty good like for me > I will take a close look at this project A recent attempt to collect known Python JITs/compilers: https://github.com/pfalcon/awesome-python-compilers (well, definitely more recent than https://wiki.python.org/moin/PythonImplementations#Compilers). And even that is not complete, I'm still too lazy to add mypyc there, as hopefully everyone knows about it anyway. -- Best regards, Paul mailto:pmis...@gmail.com ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/QAMH4QJWXMUTF5NH3FONT5V4WP4G2CCY/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: An HTTP API to list versions of Python
On 27/05/2020 18.59, Antoine Pitrou wrote: > On Tue, 26 May 2020 22:19:12 -0400 > Kyle Stanley wrote: >> >>> It could become more detailed about each minor versions, git tag, links >> to changelogs, links to the repositories, to the docs, download links, >> and so on. >> >> I don't know that it needs to be said, but for now, I think we should start >> with a minimalist approach by keeping the API focused on reducing the >> number of *existing* locations to update, rather than predicting what might >> sort of fields might be useful to include. Otherwise, it could very well >> end up becoming more work to maintain compared to what it actually saves. > > Unless unusual fields are required in the returned information, how > about using PyPI as the information store? That way, you don't have to > design a new API and implement a new backend... > > (that doesn't mean PyPI needs to host any downloadable files for Pyhon, > by the way - just the metadata) Barry and Guido own the Python project on PyPI, https://pypi.org/project/Python/ . There hasn't been an update since 2.5.0 in 2007. Does PyPI still support empty releases without files? I wouldn't mind to upload all sources on PyPI, too. Christian ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/ZRVS4UO5YBA37LFJATKGGM6GMCTL3OZD/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Optional keyword arguments
On Tue, May 26, 2020 at 9:52 AM Steven D'Aprano wrote: > On Mon, May 25, 2020 at 08:54:52PM -0700, Christopher Barker wrote: > > On Mon, May 25, 2020 at 6:37 PM Steven D'Aprano > wrote: > > > > > A NOT_SPECIFIED singleton in builtins would be pretty clear. > > > > Guido's time machine strikes again! We already have that "not > specified" > > > singleton in the builtins, with a nice repr. It's spelled "None". > > > > > well, yes and no. this conversation was in the context of "None" works > fine > > most of the time. > > Um, yes? I know what the context is, I'm pretty sure I already pointed > out that None works fine most of the time. So we already have the > feature you wanted: a sentinel value that implies "no value was passed". > That's one of the purposes of None. > This is the point -- it "implies" no value was passed -- which is usually good enough, but there is something to be said for being more explicit about that. and it's "one" of the purposes -- None has many purposes, and these sometimes (though not often) confilct / overlap with the "no value was passed" use case. If you want a *second* such sentinel value, we run into the problem I go > on to describe. > As far as I can tell -- that problem is that it still wouldn't be useful for ALL cases of not passing arguments.Which doesn't, by any means mean that it would never be useful. I would venture to guess that if such a special value existed already, it would be mostly used in cases where None would have been fine, but it would be more explicit, which I think would be a good thing. Another thing to keep in mind is that None is not, in fact, all that special. The only things (that I can think of at the moment) special about are: - it is a builtin - it is the default value passed back from function calls - It's a well established convention - anything else?? (note: it would become a more special part of the language id PEP 505 or something like it were to be adapted) That later point is key -- we all agree to use None for things like the current example: meaning no specified, but there's nothing in the language spec or None itself that requires that. And this theoretical NOT_SPECIFIED value *could* have special properties in the language, for instance: function_call(x=NOT_SPECIFIED) could be illegal. Is that a good idea? I haven't thought it out, but it *could* be done. Anyway -- all I'm suggesting is that yes, it would be nice to have another "standard" value with a more defined meaning. Is it critically important? no Would it be very disruptive? no. well, maybe yes, as we'd have a long period of people using both None and gteh new one in the same context -- and that would be even more confusing. Could there be a dozen or more other "standard" values that would be equally useful? maybe, and if that's the case, then yeah, probably not worth doing this at all. I'm not sure if this is really parallel, but this reminds me of NaN -- NaN can be the result of a calculation gone bad, and it's also used to mean "missing value", or "not set", and other use cases. And this works most of the time OK, but it IS an issue in some cases -- witness the massive discussions around how to handle missing values in numpy. Another special floating point value that specifically means "missing data" would be pretty helpful. Anyway, I'm not pushing this, and there doesn't seem to be much support, so I'm done. I am intrigued by Chris A's idea of leveraging unbound locals though. -CHB -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/ML3ZDE3P3GQAUUJV3EHXPLVGI3SX2MUN/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: An HTTP API to list versions of Python
On Tue, 26 May 2020 22:19:12 -0400 Kyle Stanley wrote: > > > It could become more detailed about each minor versions, git tag, links > to changelogs, links to the repositories, to the docs, download links, > and so on. > > I don't know that it needs to be said, but for now, I think we should start > with a minimalist approach by keeping the API focused on reducing the > number of *existing* locations to update, rather than predicting what might > sort of fields might be useful to include. Otherwise, it could very well > end up becoming more work to maintain compared to what it actually saves. Unless unusual fields are required in the returned information, how about using PyPI as the information store? That way, you don't have to design a new API and implement a new backend... (that doesn't mean PyPI needs to host any downloadable files for Pyhon, by the way - just the metadata) Regards Antoine. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/SWYQBR645BWSSMC2NF54D4ZXM76FPWRQ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Optional keyword arguments
Greg Ewing writes: > "Did the user supply a value for this optional argument?" is a > simple and reasonable question to ask. True. > It deserves to have a simple and direct way of answering it that > always works. "Deserves"? I wouldn't go farther than "it might be fun to have" that. In Emacs Lisp, it's useful to defend against users who don't update their package libraries with #'boundp and #'fboundp checks. These invariably occur in top-level forms, though, not on function arguments. But what's the use case for this magical predicate? Writing a nastygram to the user's boss if they dare to use gregs-package._sentinels._af5d8a21858f42808c9bcc17012b77bcc2fd6ab3b071dbd4a05f13f410470541 as an actual argument? ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/HFO6BK35FTMUJPKNAWIPLYSI6FDHUGIA/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Python JIT Compilation Thoughts
Thanks Guido !! I have not known about `pyston` ... It is pretty good like for me I will take a close look at this project ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/PLC4LASBVE7TBQLDGAKY2HANSB5E4JYR/ Code of Conduct: http://python.org/psf/codeofconduct/
