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
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
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
(I assume that this list is appropriate for this topic, but if it
isn't, I will be grateful for being redirected to the appropriate
place.)
It seems that warnings behave differently in Python 2 and Python
3. Consider the following script.
def func():
Am 07.12.2011 02:23, schrieb Cameron Simpson:
On 30Nov2011 22:10, Raymond Hettinger raymond.hettin...@gmail.com 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
Georg Brandl wrote:
Am 07.12.2011 02:23, schrieb Cameron Simpson:
On 30Nov2011 22:10, Raymond Hettinger raymond.hettin...@gmail.com 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
On Wed, Dec 7, 2011 at 11:00 AM, Ethan Furman et...@stoneleaf.us 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
Georg Brandl g.bra...@gmx.net 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
-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 raymond.hettin...@gmail.com
wrote: | When updating the documentation, please don't go overboard
with warnings. | The
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
On 30Nov2011 22:10, Raymond Hettinger raymond.hettin...@gmail.com 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
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've ensured
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
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
The docs for the subprocess module currently have SEVEN
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
On Thu, Dec 1, 2011 at 4:10 PM, Raymond Hettinger
raymond.hettin...@gmail.com 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
On Thu, Dec 1, 2011 at 5:15 PM, Glyph gl...@twistedmatrix.com 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
On Thu, Dec 1, 2011 at 5:36 PM, Nick Coghlan ncogh...@gmail.com wrote:
On Thu, Dec 1, 2011 at 5:15 PM, Glyph gl...@twistedmatrix.com 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
Hi, there has been a problem in blender3d for 6~ years or so thats
eluded me, I decided to look into today.
- Whenever the a script raises a warnings python prints out binary
garbage in the console. Some users complain when they run python games
in blender they get beeps coming from the PC
import os
os.tmpnam()
RuntimeWarning: tmpnam is a potential security risk to your program
Are these runtime warnings necessary? Suppressing these warnings is a pita for
one-off uses of os.tmpnam() or os.tempnam().
I would hate for this sort of thing to propagate throughout the standard
On Thu, 5 Feb 2009 08:35:30 -0800, Raymond Hettinger pyt...@rcn.com 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
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
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 library
Jaroslav Pachola pachola at 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,
With the 2.6 final release impending, the Twisted community buildbot is
still red, http://bit.ly/zFymN, but there only seems to be one real
issue: the warn_explicit change. This seems like it could be a pretty
minor bit of maintenance to clear up on our end, if Python provided the
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, http://bit.ly/zFymN, but there only seems to be one real issue:
the warn_explicit change. This seems like it could be a pretty minor bit of
maintenance
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, http://bit.ly/zFymN, but there only seems to be one real issue:
the warn_explicit change. This seems like it could be a pretty minor bit of
maintenance
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
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
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.
Thanks for the
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 plan? I would like to see Py3k warnings for these
kinds of imports at least.
--
Cheers,
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 plan? I
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 in the
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 triggers for
Hi,
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 in the build process for
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, since
gcc 4.0.1 on OS X is spitting out some warnings about libffi:
build/temp.darwin-8.5.0-Power_Macintosh-2.5/libffi/include/ffi.h:191:
warning: function declaration isn't a prototype
build/temp.darwin-8.5.0-Power_Macintosh-2.5/libffi/include/ffi.h:204:
warning: function declaration isn't a prototype
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 write
38 matches
Mail list logo
