Re: [Python-Dev] Warnings behave differently in Python 2 and Python 3?

On 11/14/2016 4:44 PM, Christoph Groth wrote: Thanks, Victor, for the link to the bug fix! I suspected that the original mechanism was something like that, but I believed that it was so by design. I find it a bit surprising that CPython gets changed between versions in backwards-incompatible wa

Re: [Python-Dev] Warnings behave differently in Python 2 and Python 3?

Thanks, Victor, for the link to the bug fix! I suspected that the original mechanism was something like that, but I believed that it was so by design. I find it a bit surprising that CPython gets changed between versions in backwards-incompatible ways (even if it’s a bug fix) without a notic

Re: [Python-Dev] Warnings behave differently in Python 2 and Python 3?

You are looking for the bug fix http://bugs.python.org/issue4180: "warnings.simplefilter("always") does not make warnings always show up" Python 2.7 has a bug, Python 3.4.3+ behaves correctly. It is surprising that Python 3.4.0 and Python 3.4.3 behaves differently :-) (Ubuntu 14.04 uses Python 3

Re: [Python-Dev] Warnings

Georg Brandl writes: > Oh, come on, surely this doesn't effect the casual reader? Casual readers aren't effective in any case; you want to hear the opinions of those who care. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/ma

Re: [Python-Dev] Warnings

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/07/2011 01:22 PM, Georg Brandl wrote: > Am 07.12.2011 02:23, schrieb Cameron Simpson: >> On 30Nov2011 22:10, Raymond Hettinger >> wrote: | When updating the documentation, please don't go overboard >> with warnings. | The docs need to be worded

Re: [Python-Dev] Warnings

Georg Brandl writes: > Am 07.12.2011 02:23, schrieb Cameron Simpson: > > This assures that files are flushed [...] > > > > It does not. It _ensures_ that files are flushed. The doco style > > "affirmative tone" _assures_. The coding practice _ensures_! > > Oh, come on, surely this doesn't effe

Re: [Python-Dev] Warnings

On Wed, Dec 7, 2011 at 11:00 AM, Ethan Furman wrote: > > No, of course not -- although it might /affect/ said reader by causing > him/her to think, "I don't think that word means what you think it means..." >  ;) > > Seriously, it's best to use the correct words with the correct meanings.  If > so

Re: [Python-Dev] Warnings

Georg Brandl wrote: Am 07.12.2011 02:23, schrieb Cameron Simpson: On 30Nov2011 22:10, Raymond Hettinger wrote: | When updating the documentation, please don't go overboard with warnings. | The docs need to be worded affirmatively -- say what a tool does and show how to use it correctly. | See

Re: [Python-Dev] Warnings

Am 07.12.2011 02:23, schrieb Cameron Simpson: > On 30Nov2011 22:10, Raymond Hettinger wrote: > | When updating the documentation, please don't go overboard with warnings. > | The docs need to be worded affirmatively -- say what a tool does and show > how to use it correctly. > | See http://docs.p

Re: [Python-Dev] Warnings

On Dec 6, 2011, at 7:23 PM, Cameron Simpson wrote: > This assures that files are flushed [...] > > It does not. It _ensures_ that files are flushed. The doco style "affirmative > tone" _assures_. The coding practice _ensures_! > > Pedanticly, > -- > Cameron Simpson I can assure you that I'v

Re: [Python-Dev] Warnings

On 30Nov2011 22:10, Raymond Hettinger wrote: | When updating the documentation, please don't go overboard with warnings. | The docs need to be worded affirmatively -- say what a tool does and show how to use it correctly. | See http://docs.python.org/documenting/style.html#affirmative-tone I com

Re: [Python-Dev] Warnings

Am 01.12.2011 07:10, schrieb Raymond Hettinger: > When updating the documentation, please don't go overboard with warnings. > The docs need to be worded affirmatively -- say what a tool does and show how > to > use it correctly. > See http://docs.python.org/documenting/style.html#affirmative-tone

Re: [Python-Dev] Warnings

On Thu, Dec 1, 2011 at 5:36 PM, Nick Coghlan wrote: > On Thu, Dec 1, 2011 at 5:15 PM, Glyph wrote: >> I think both of these documents point to a need for a recommended idiom for >> discussing security, or at least common antipatterns, within the Python >> documentation.  I like the IETF's "securi

Re: [Python-Dev] Warnings

On Thu, Dec 1, 2011 at 5:15 PM, Glyph wrote: > I think both of these documents point to a need for a recommended idiom for > discussing security, or at least common antipatterns, within the Python > documentation.  I like the IETF's "security considerations" section, because > it separates things

Re: [Python-Dev] Warnings

On Thu, Dec 1, 2011 at 4:10 PM, Raymond Hettinger wrote: > When updating the documentation, please don't go overboard with warnings. > The docs need to be worded affirmatively -- say what a tool does and show > how to use it correctly. > See http://docs.python.org/documenting/style.html#affirmativ

Re: [Python-Dev] Warnings

On Dec 1, 2011, at 1:10 AM, Raymond Hettinger wrote: > When updating the documentation, please don't go overboard with warnings. > The docs need to be worded affirmatively -- say what a tool does and show how > to use it correctly. > See http://docs.python.org/documenting/style.html#affirmative-

Re: [Python-Dev] Warnings

Jaroslav Pachola mageo.cz> writes: > > What's the replacement in the library then, in case that I just want to > create > a unique file name and I don't care about the possible issues? Three alternatives I'm thinking of: - tempfile.mktemp(): the doc says it has been deprecated since 2.3, but i

Re: [Python-Dev] Warnings

Hello, Dne Thursday 05 February 2009 Antoine Pitrou napsal(a): > Hello, > > > I agree. The best thing to do would be to deprecate the Python wrappers > > around insecure C functions and then remove them after a couple releases. > > They have been removed in 3.0. What's the replacement in the lib

Re: [Python-Dev] Warnings

Hello, > I agree. The best thing to do would be to deprecate the Python wrappers > around insecure C functions and then remove them after a couple releases. They have been removed in 3.0. > Why does Python offer > this attractive nuisance? Well, there was a time when security concerns were a

Re: [Python-Dev] Warnings

On Thu, 5 Feb 2009 08:35:30 -0800, Raymond Hettinger wrote: import os os.tmpnam() RuntimeWarning: tmpnam is a potential security risk to your program This warning is a reflection of the fact that (at least) the glibc authors think you shouldn't be using tmpnam(2). If you compile a C progra

Re: [Python-Dev] 'warnings' module changes still breaking Twisted, still looking for a fix

On Thu, Sep 4, 2008 at 3:39 PM, <[EMAIL PROTECTED]> wrote: > On 10:18 pm, [EMAIL PROTECTED] wrote: >> >> That's why catch_warning keeps track of the warnings filter too, so >> you can call warnings.simplefilter("always") within the context >> manager and the filter state will be restored. > > Than

Re: [Python-Dev] 'warnings' module changes still breaking Twisted, still looking for a fix

On 10:35 pm, [EMAIL PROTECTED] wrote: It is not hard to force an import of warnings to use the pure Python version and totally ignore the C implementation. See test_warnings on how to pull that off. Then you can do your hack of overriding warn_explicit(). Benjamin Peterson's recommendation sou

Re: [Python-Dev] 'warnings' module changes still breaking Twisted, still looking for a fix

On 10:18 pm, [EMAIL PROTECTED] wrote: That's why catch_warning keeps track of the warnings filter too, so you can call warnings.simplefilter("always") within the context manager and the filter state will be restored. Thanks for the pointer - this is interesting. I misunderstood the way the wa

Re: [Python-Dev] 'warnings' module changes still breaking Twisted, still looking for a fix

On Thu, Sep 4, 2008 at 3:11 PM, <[EMAIL PROTECTED]> wrote: > > With the 2.6 final release impending, the Twisted community buildbot is > still red, , but there only seems to be one real issue: > the warn_explicit change. This seems like it could be a pretty minor bit of > mai

Re: [Python-Dev] 'warnings' module changes still breaking Twisted, still looking for a fix

On Thu, Sep 4, 2008 at 5:11 PM, <[EMAIL PROTECTED]> wrote: > > With the 2.6 final release impending, the Twisted community buildbot is > still red, , but there only seems to be one real issue: > the warn_explicit change. This seems like it could be a pretty minor bit of > mai

Re: [Python-Dev] Warnings for intra-package imports

On Thu, Jul 24, 2008 at 10:53 PM, Benjamin Peterson <[EMAIL PROTECTED]> wrote: > I was just reading up on PEP 328. In the "Timeline" section, it > mentions that intra-package imports should raise a DeprecationWarning > in 2.6. This doesn't seem to be implemented currently. > > Is this still the pla

Re: [Python-Dev] warnings about missing __init__.py in toplevel directories

On 27-mei-2006, at 8:49, Martin v. Löwis wrote: > Ronald Oussoren wrote: >> Some time ago a warning was introduced for directories on sys.path >> that don't contain an __init__.py but have the same name as a >> package/ >> module that is being imported. >> >> Is it intentional that this trigger

Re: [Python-Dev] warnings about missing __init__.py in toplevel directories

Ronald Oussoren wrote: > Some time ago a warning was introduced for directories on sys.path > that don't contain an __init__.py but have the same name as a package/ > module that is being imported. > > Is it intentional that this triggers for toplevel imports? These > warnings are triggered i

Re: [Python-Dev] warnings about missing __init__.py in toplevel directories

On 5/26/06, Ronald Oussoren <[EMAIL PROTECTED]> wrote: > Some time ago a warning was introduced for directories on sys.path > that don't contain an __init__.py but have the same name as a package/ > module that is being imported. > > Is it intentional that this triggers for toplevel imports? Yes,

Re: [Python-Dev] warnings in libffi

Brett Cannon wrote: > All of them are for function parameters of function pointers (``void > (*fn)(void)`` and such) when used in both function prototypes and > function declarations. Do we fix these ourselves, or do we report > them to the libffi maintainers (or are whom)? If you don't have writ