Re: [Python-Dev] Is it useful to update cgitb module?
cgitb is useful even outside of cgi scripts. I've used "cgitb.enable(format='text')" in the several scripts to get "better" exceptions. On Sun, 8 Apr 2018 at 08:52 Glenn Linderman wrote: > On 4/7/2018 9:45 PM, Alex Walters wrote: > > Are there people still actively developing new cgi scripts in python? I know > some modern HTTPDs don’t even support classic cgi without some kind of > fastcgi daemon in between. I am aware that some parts of various wsgi tools > use the cgi module, but is the cgitb module useful for them? > > > Yes. I have several web sites and applications built as Python CGI > scripts. cgitb is extremely useful. > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/jmcs%40jsantos.eu > ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Slow down...
Hi, I would like to see this go even further and have a tick-tock approach to python versions, i.e. adopt new syntax and other large changes on one version (for example odd versions) and polish everything up in the next (even versions). Best regards, João Santos On Mon, 7 May 2018 at 11:19 Ivan Levkivskyi wrote: > On 7 May 2018 at 03:25, Nick Coghlan wrote: > >> On 7 May 2018 at 11:30, Dan Stromberg wrote: >> >>> I'd very much like a live in a world where Jython and IronPython and >>> MicroPython and Cython and Pyjamas can all catch up and implement >>> Python 3.7, 3.8, and so forth. >>> >> >> I'm inclined to agree that a Python 3.8 PEP in the spirit of the PEP 3003 >> language moratorium could be a very good idea. Between matrix >> multiplication, enhanced tuple unpacking, native coroutines, f-strings, and >> type hinting for variable assignments, we've had quite a bit of syntactic >> churn in the past few releases, and the rest of the ecosystem really hasn't >> caught up on it all yet (and that's not just other implementations - it's >> training material, online courses, etc, etc). >> >> If we're going to take such a step, now's also the time to do it, since >> 3.8 feature development is only just getting under way, and if we did >> decide to repeat the language moratorium, we could co-announce it with the >> Python 3.7 release. >> >> > These are all god points. I think it will be a good idea to take a little > pause with syntactic additions and other "cognitively loaded" changes. On > the other hand, I think it is fine to work on performance improvements > (start-up time, import system etc.), internal APIs (like simplifying > start-up sequence and maybe even C API), and polishing corner > cases/simplifying existing constructs (like scoping in comprehensions that > many people find confusing). > > IOW, I think the PEP should describe precisely what is OK, and what is not > OK during the moratorium. > > -- > Ivan > > > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/jmcs%40jsantos.eu > ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Arbitrary non-identifier string keys when using **kwargs
*locals *and *globals* are documented as dictionaries (for example exec's
documentation states that " If only *globals* is provided, it must be a
dictionary") but __dict__ is described as " [a] dictionary or other mapping
object".
On Sun, 7 Oct 2018 at 19:38, Chris Barker via Python-Dev <
python-dev@python.org> wrote:
> On Fri, Oct 5, 2018 at 3:01 PM Brett Cannon wrote:
>
>> I'm also fine with saying that keys in **kwargs that are not proper
>> identifiers is an implementation detail.
>>
>
> It's not just **kwargs -- you can also use arbitrary names with setattr()
> / getattr() :
>
> In [6]: setattr(foo, "4 not an identifier", "this works")
>
> In [7]: getattr(foo, "4 not an identifier")
> Out[7]: 'this works'
>
> Which brings up a question I've had for years -- is the fact that cPython
> uses a regular old dict for namespaces (and **kwargs) part of the language
> spec, or an implementation detail?
>
> I would say that for the get/setattr() example, it is kinda handy when you
> want to use a class instance to model some external data structure that may
> have different identifier rules. Though I tend to think that's mingling
> data and code too much.
>
> -CHB
>
>
>>
>> On Thu, 4 Oct 2018 at 02:20, Serhiy Storchaka
>> wrote:
>>
>>> 04.10.18 11:56, Steven D'Aprano пише:
>>> > While keyword arguments have to be identifiers, using **kwargs allows
>>> > arbitrary strings which aren't identifiers:
>>> >
>>> > py> def spam(**kwargs):
>>> > print(kwargs)
>>> >
>>> > py> spam(**{"something arbitrary": 1, '\n': 2})
>>> > {'something arbitrary': 1, '\n': 2}
>>> >
>>> >
>>> > There is some discussion on Python-Ideas on whether or not that
>>> > behaviour ought to be considered a language feature, an accident of
>>> > implementation, or a bug.
>>> >
>>> > Can we get some guidence on this please?
>>>
>>> This is an implementation detail. Currently CPython doesn't ensure that
>>> keyword argument names are identifiers for performance reasons. But this
>>> can be changed in future versions or in other implementations.
>>>
>>> ___
>>> Python-Dev mailing list
>>> Python-Dev@python.org
>>> https://mail.python.org/mailman/listinfo/python-dev
>>> Unsubscribe:
>>> https://mail.python.org/mailman/options/python-dev/brett%40python.org
>>>
>> ___
>> Python-Dev mailing list
>> Python-Dev@python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
>> https://mail.python.org/mailman/options/python-dev/chris.barker%40noaa.gov
>>
>
>
> --
>
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR&R(206) 526-6959 voice
> 7600 Sand Point Way NE (206) 526-6329 fax
> Seattle, WA 98115 (206) 526-6317 main reception
>
> chris.bar...@noaa.gov
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/jmcs%40jsantos.eu
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] LibSSH Vulnerability
Slightly Off-Topic, but more relevant for python developers. Paramiko also had a very similar vulnerability: https://github.com/paramiko/paramiko/issues/1283. On Thu, 18 Oct 2018 at 18:56, Antoine Pitrou wrote: > On Thu, 18 Oct 2018 17:41:29 +0100 > MRAB wrote: > > I wondered if any of you have heard of this: > > > > Hacker: I'm logged in. New LibSSH Vulnerability: OK! I believe you. > > > https://www.bleepingcomputer.com/news/security/hacker-im-logged-in-new-libssh-vulnerability-ok-i-believe-you/ > > AFAIK, this doesn't have any to do with OpenSSH, which practically > everyone uses on Unix. > > Regards > > Antoine. > > > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/jmcs%40jsantos.eu > ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
