Antoine Pitrou added the comment:
> > Note that extension (non-builtin) types will need to have their
> > __qualname__ fixed before their methods' __qualname__ is usable:
> >
> > >>> collections.deque.__qualname__
> > 'deque'
>
>
Antoine Pitrou added the comment:
If _PyDict_SetItemUsingHash is module-private, it should be declared "static".
Also, better if it follows the usual naming of static functions inside that C
file (i.e. "dict_some_lowercase_name").
--
stage: needs p
Antoine Pitrou added the comment:
> "It doesn't happen in Python 3"
>
> Yet the cheap/unnecessary pre-imports of ssl in those other mentioned
> socket using libs (urllib (cgi!),httplib,smtplib,pop,imap...) exist
> there. socket is rarely used directly, so not much
Antoine Pitrou added the comment:
The patch looks ok to me. I'll let Raymond make the final call.
--
___
Python tracker
<http://bugs.python.org/is
Antoine Pitrou added the comment:
> (I often wonder why software today isn't much faster than years ago -
> though the nominal speed of hardware increases tremendously. package
> sizes grow, without appropriate growth of functionality. This is one
> example how the rescourc
Antoine Pitrou added the comment:
> But if I understand correctly, the slowdown in string formatting is
> expected, so we can indeed close this.
Well, expected doesn't mean it shouldn't be improved, so finding a way to speed
it up would be nice ;)
(probably difficult, though)
Antoine Pitrou added the comment:
Very high-level comments on your patch:
- why an empty "dtrace" module?
- I'm worried that you're adding lots of delicate code inside critical core
functions. Perhaps most of it can be factored out in separate functions living
in another
Antoine Pitrou added the comment:
I'm not convinced by the decorator approach. Why not simply add "with
self.lock" at the beginning of each protected method? It would actually save a
function call indirection.
--
stage: -> patch review
versions: +Pyth
Antoine Pitrou added the comment:
> Are you suggesting to enable thread-synchronization by default and get
> rid of explicit "synchronized" argument?
That would be even better indeed, if you find out that there's no
significant pe
Antoine Pitrou added the comment:
Ok, a couple of further (minor) issues:
- I don't think AssertionError is the right exception type. TypeError should be
used when a type mismatches (e.g. "not an unicode object");
- you don't need to check for d_type being NULL, since other
Antoine Pitrou added the comment:
> Versions #2 and #3 have the same cost, so it's better to get rid of
> the explicit argument and always use the lock (version #3).
> Differences between #1 and #3 suggest that introducing the lock
> obviously have a cost though.
> It'
Antoine Pitrou added the comment:
> Overall I wonder why you post here on the main topic "resource usage",
> when you don't care about issues of magnitude 2x memory usage.
Because you are talking about a fixed overhead of a mere 2MB (IIUC),
which is moreover shared betwee
Antoine Pitrou added the comment:
I think most of these shouldn't be removed, as it would make porting from 2.x
significantly more tedious.
Things that I think can be removed:
- max_buffer_size (io is new and that argument was never used by anybody)
- get_prefix / set_prefix (the int
Antoine Pitrou added the comment:
About method_qualname.patch:
- apparently you forgot to add BuiltinFunctionPropertiesTest in test_main()?
- a static method keeps a reference to the type: I think it's ok, although I'm
not sure about the consequences (Guido, would you have an idea?
Antoine Pitrou added the comment:
> - Interactive interpreter invocation: 517 blocks, 95128 bytes.
Note that http://bugs.python.org/issue13390 also proposes to count
allocations in the interpreter.
--
___
Python tracker
<http://bugs.pyth
Antoine Pitrou added the comment:
> Notice too, that the data I am showing is the extra memory I am using
> for the dtrace stack helper, not all python memory (if you check the
> dtrace script, I only contabilize "PyMem_Malloc()" when called from
> "PyCode_New()&quo
Antoine Pitrou added the comment:
> Couldn't this be linked to #11564 (pickle not 64-bit ready)?
Well, I don't know anything about numpy, but:
>>> 196 * 24
4704
>>> 196 * 24 * 8 # assuming 8 bytes per float
37632
>>> 2**31
21
Antoine Pitrou added the comment:
Oh, what's more interesting is that it works here (Python 2.7.1 and numpy 1.6.1
under Mageia with 8GB RAM). Looking at a pickle disassembly, the only
remarkable thing is the presence of a long binary string (the raw serialization
of all IEEE floats),
Antoine Pitrou added the comment:
> Filip: Is there a reasons for using a nonlocal count rather than e.g.
> self.count? Otherwise the test looks good.
Eric, please, could we stop such pointless nitpicking about one's
stylistic preferences? "nonlocal" is as good as any oth
Antoine Pitrou added the comment:
> Well, if this is going to be applied to 2.7, "nonlocal" is invalid
> syntax there.
Ah, good point.
--
___
Python tracker
<http://bugs.py
Antoine Pitrou added the comment:
I suppose the status can be switched to "closed"?
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.o
Antoine Pitrou added the comment:
+1.
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/issue13575>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
> Only worry is that codecs.latin_1_encode.__module__ is '_codecs', and
> _codecs is undocumented.
It seems we have to choose between two evils here. Given that the
codecs.latin_1_encode produces more compact pickles, I'd say go for i
Antoine Pitrou added the comment:
> I would like to continue working on this test, but incoming week is
> pretty intensive for me. Is it ok if I returned to working on this
> during the weekend?
Of course. There's no rush.
(I'm really not sure it should go in 2.7 and 3.2; t
Antoine Pitrou added the comment:
Looks ok to me.
--
___
Python tracker
<http://bugs.python.org/issue13593>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Antoine Pitrou :
--
versions: +Python 3.3
___
Python tracker
<http://bugs.python.org/issue13591>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
> I'm not sure having the pattern in the repr will make it more readable,
> since the regex might even be very long.
Hmm, I think it's a reasonable feature request myself.
Oops, I meant "enhancement", not "feature request"
Antoine Pitrou added the comment:
> ISTM that .pattern is the one way to do it.
To me this is like saying the repr() of functions should not show their
name since .__name__ is the one way to do it. repr() is useful for
debugging and logging, why not make it more use
Antoine Pitrou added the comment:
We could force sys.stderr to be always line-buffered if that's better than the
current settings.
--
components: +IO
nosy: +benjamin.peterson, pitrou, stutzbach
versions: -Python 3.1, Python 3.4
___
Python tr
Antoine Pitrou added the comment:
That's a good point. Then perhaps call the flag "wait" or "blocking", since it
avoids false positives and is more explicit than "async"?
--
___
Python tracker
Antoine Pitrou added the comment:
> I'm surprised to hear that stderr is line buffered by default.
> Historically stderr is never buffered (at least on POSIX) and for good
> reason: errors should be seen immediately
>
> Was this an oversight in migrating stdin/out/err
New submission from Antoine Pitrou :
In issue13597, Philip Jenvey points out:
“I'm surprised to hear that stderr is line buffered by default. Historically
stderr is never buffered (at least on POSIX) and for good reason: errors should
be seen immediately”
Recent changes to the IO
Antoine Pitrou added the comment:
> With issue13449 fixed I think we can now provide this functionnality by
> adding a specific section into asyncore doc which explains how to use
> asyncore in conjunction with sched module.
How woul
Antoine Pitrou added the comment:
> while 1:
> asyncore.loop(timeout=1.0, count=1) # count=1 makes loop() return after
> 1 loop
> scheduler.run(blocking=False)
Isn't that both ugly and imprecise?
The right way to do it is to set the timeout of the select()
Antoine Pitrou added the comment:
(I've opened issue13601 for the possible behaviour change)
--
___
Python tracker
<http://bugs.python.org/issue13597>
___
___
Antoine Pitrou added the comment:
> Anybody else than Benjamin and Meador please comment on this.
I don't know why we would want to maintain this in the stdlib. We would also
need a dedicated maintainer so that efficient algorithms are chosen and
implemented.
Such functions are avai
Antoine Pitrou added the comment:
Here is a patch. Can someone take a look?
--
Added file: http://bugs.python.org/file23962/oserror_new.patch
___
Python tracker
<http://bugs.python.org/issue12
Antoine Pitrou added the comment:
The patch doesn't appear to have the necessary mechanics to pass the new
arguments from the import machinery when an ImportError is raised, is this
deliberate?
Also, I'm not sure why the new arguments are keyword-only.
--
nosy: +pitrou
s
Changes by Antoine Pitrou :
--
nosy: +haypo, loewis
stage: -> patch review
___
Python tracker
<http://bugs.python.org/issue13604>
___
___
Python-bugs-list mai
Antoine Pitrou added the comment:
Thanks for the writeup, Mark. Here is a patch, calling PyType_Modified in the
type's (not the instance's) tp_clear.
--
resolution: fixed ->
status: closed -> open
Added file: http://bugs.python.org/file23963/
Antoine Pitrou added the comment:
> I have added a call to PyType_Modified in type_clear (as well as
> type_set_name and type_set_qualname, which also modify the type).
Can __name__ and __qualname__ be looked up through the method
Antoine Pitrou added the comment:
Updated patch. I've renamed oserror_post_init to oserror_init. Also addressed
Nick's other comments.
--
Added file: http://bugs.python.org/file23965/oserror_new2.patch
___
Python tracker
<http://bu
Antoine Pitrou added the comment:
> Since PyType_Modified is generally called whenever a type is modified,
> it is likely to act as a guardian for any future optimisations that
> require classes to be unchanged.
>
> Thus, given these two reasons, it seems wise to call
Antoine Pitrou added the comment:
Hopefully this is fixed for good now. Thank you!
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Antoine Pitrou added the comment:
Fixed now.
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Antoine Pitrou added the comment:
> Amaury has asked for more comments (and I agree). However, I'm not sure what
> level of detail would be appropriate. As an example, I've posted the full
> proof of the x87 modular multiplication in umodarith.h.
>
>
> Even with
Changes by Antoine Pitrou :
--
stage: -> patch review
___
Python tracker
<http://bugs.python.org/issue13594>
___
___
Python-bugs-list mailing list
Unsubscri
Antoine Pitrou added the comment:
> Line-buffering should be good enough since in practice errors messages
> are always terminated by a newline.
What I think too.
> I'm hesitant to make it line-buffered by default when directed to a
> file, since this could significantly sl
Antoine Pitrou added the comment:
Oops, I forgot the last two questions:
> Maybe we need better command-line control to override the defaults?
We already have -u to switch all stdio to unbuffered. This issue proposes to
make stderr line-buffered/unbuffered by default, since it
Antoine Pitrou added the comment:
Should be ok now.
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Changes by Antoine Pitrou :
--
nosy: +benjamin.peterson
stage: -> patch review
versions: +Python 3.2, Python 3.3
___
Python tracker
<http://bugs.python.org/issu
Changes by Antoine Pitrou :
--
nosy: +benjamin.peterson, ncoghlan
stage: -> patch review
___
Python tracker
<http://bugs.python.org/issue13607>
___
___
Python-
Antoine Pitrou added the comment:
Well, do you want to propose a patch yourself?
See http://docs.python.org/devguide/ for how to contribute a patch.
--
nosy: +pitrou
stage: -> needs patch
versions: +Python 3.3
___
Python tracker
&l
Changes by Antoine Pitrou :
--
nosy: +benjamin.peterson
___
Python tracker
<http://bugs.python.org/issue13610>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Antoine Pitrou :
--
nosy: +flox
___
Python tracker
<http://bugs.python.org/issue13611>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
Is there any reason why this issue is still open?
--
___
Python tracker
<http://bugs.python.org/issue6715>
___
___
Python-bug
Antoine Pitrou added the comment:
"fullname" is technically wrong:
>>> import logging.bar
Traceback (most recent call last):
File "", line 1, in
ImportError: No module named 'bar'
"module_name" sounds fine and explicit enough to me. Also, as
Antoine Pitrou added the comment:
Updated patch for 3.2.
--
stage: -> patch review
versions: +Python 3.2 -Python 2.6
Added file: http://bugs.python.org/file23975/inspect-and-pydoc-bug2.patch
___
Python tracker
<http://bugs.python.org/iss
Antoine Pitrou added the comment:
Updated patch that adds a test for classifying builtin types (checks that
``inspect.classify_class_attrs(type)`` does not throw as in issue13581).
--
___
Python tracker
<http://bugs.python.org/issue1
Changes by Antoine Pitrou :
Added file: http://bugs.python.org/file23976/inspect-and-pydoc-bug3.patch
___
Python tracker
<http://bugs.python.org/issue1785>
___
___
Pytho
Changes by Antoine Pitrou :
--
nosy: +neologix
___
Python tracker
<http://bugs.python.org/issue12809>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
The clearing the dict and list freelists has been added independently, so I
committed the part of the patch pertaining to sets. Thank you!
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
versions: +Python 3.3 -P
Changes by Antoine Pitrou :
--
nosy: +neologix
___
Python tracker
<http://bugs.python.org/issue5424>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
Committed in 3.x. I won't bother backporting to 2.x. Thank you!
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions: +Python 3.3 -Python 2.7, Python 3.1
Changes by Antoine Pitrou :
--
nosy: +neologix
___
Python tracker
<http://bugs.python.org/issue9975>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
Patch committed in 3.3 (default branch), thank you!
--
nosy: +pitrou
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions: +Python 3.3 -Python 3.1, Python 3.2
_
Antoine Pitrou added the comment:
Ok, a couple of general comments:
- there is no point having a separate module for a single function; I think the
os module (and posixmodule.c for the C side) is a reasonable place where to put
this
- C code should be indented with 4 spaces increments and no
Antoine Pitrou added the comment:
Ah, I see. It's a bit of a pity not to be able to load files > 1GB, especially
on a 64-bit build (!). Perhaps cPickle could be made partly 64-bit compatible?
Or at least, indeed, do a proper anti-overfl
Changes by Antoine Pitrou :
--
stage: -> patch review
type: -> behavior
versions: +Python 3.3
___
Python tracker
<http://bugs.python.org/issue13530>
___
__
Changes by Antoine Pitrou :
--
nosy: +gvanrossum
versions: +Python 3.3 -Python 3.4
___
Python tracker
<http://bugs.python.org/issue13610>
___
___
Python-bug
Changes by Antoine Pitrou :
--
assignee: collinwinter ->
___
Python tracker
<http://bugs.python.org/issue13621>
___
___
Python-bugs-list mailing list
Unsubscri
Changes by Antoine Pitrou :
--
nosy: +haypo, pitrou
___
Python tracker
<http://bugs.python.org/issue13621>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
Just a note: performance reports shouldn't be assigned to the "benchmarks"
category, except if the problem is in the benchmarks themselves.
--
assignee: collinwinter ->
components: +Interpreter Core -Benchmarks
vers
Antoine Pitrou added the comment:
I think there's a problem here:
+self->data = realloc(self->data, self->size * sizeof(PyObject *));
+if (self->data == NULL)
goto nomemory;
If realloc() fails, the old data pointer is lost and therefore will never get
fr
Antoine Pitrou added the comment:
There's a typo in the patch: it's PyErr_Occurred (two r's), not PyErr_Occured.
Otherwise, looks good to me.
--
stage: needs patch -> patch review
___
Python tracker
<http://bugs.
Antoine Pitrou added the comment:
Committed now. Thank you for the patch!
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Antoine Pitrou added the comment:
> New version.
Looks good to me.
--
___
Python tracker
<http://bugs.python.org/issue13555>
___
___
Python-bugs-list mai
Antoine Pitrou added the comment:
It's not obvious to me which APIs should be used to provide such support.
Python mostly uses high-level OpenSSL APIs, and lets OpenSSL load certificates.
Do you want to try writing a patch? General instructions on how to contribute
can be found at
Antoine Pitrou added the comment:
The ssl module doesn't directly handle keys, it just gives a PEM file to
OpenSSL's ssl functions. So I don't understand what should be done precisely
here, or even if something has to be done at all.
--
nosy: +pitrou
type: -> en
Antoine Pitrou added the comment:
Well the OpenSSL docs say “DH_generate_parameters() may run for several hours
before finding a suitable prime”, which sounds like a good reason not to do it
every time your program is run.
Anyway, SSL_CTX_set_tmp_dh() should allow us to set DH parameters on
Antoine Pitrou added the comment:
The definition of __eq__ is wrong: it shouldn't compare the hashes since the
hash() function isn't injective. For example, 0 and "" have equal hashes, yet
they are unequal.
--
___
P
Antoine Pitrou added the comment:
Something I forgot: you should also test the "!=" operator in the tests.
--
___
Python tracker
<http://bugs.python.
Antoine Pitrou added the comment:
Ok, so you are talking specifically about ECDH? Or is there something to be
done for generic EC support?
OpenSSL has a SSL_CTX_set_tmp_dh() function (macro, actually), but it's
undocumented. Best bet is probably to follow ssl/ssltest.c (OpenSSL source
Antoine Pitrou added the comment:
Already fixed in #12626.
--
resolution: -> duplicate
stage: needs patch -> committed/rejected
status: open -> closed
superseder: -> run test cases based on a glob filter
___
Python tracker
<http://
Antoine Pitrou added the comment:
Patch now committed to all 3 branches. Thanks for contributing!
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Changes by Antoine Pitrou :
--
nosy: +dmalcolm
___
Python tracker
<http://bugs.python.org/issue13628>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
Here is a patch adding a set_ecdh_curve() method on SSL contexts, and a
ssl.OP_SINGLE_ECDH_USE option flag. This is enough to enable ECDH with
compatible clients (I've tested with Firefox and openssl s_client).
--
keywords: +patch
stage: needs
Antoine Pitrou added the comment:
Charles-François's patch looks good to me.
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/issue11867>
___
___
Antoine Pitrou added the comment:
> So, with this patch it should be possible to strictly enable ciphers such as:
> ECDHE-RSA-AES256-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA1
> ECDHE-ECDSA-AES256-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA1
> ECDH-RSA-AES256-SHA
Antoine Pitrou added the comment:
> Wow, i saw your patch for ECC SSL ciphers on
> http://bugs.python.org/issue13627 .
>
> Do you think we can use the same method/concept as
> ssl.OP_SINGLE_ECDH_USE but ssl.OP_SINGLE_DH_USE for
Antoine Pitrou added the comment:
Apparently it's just a matter of exposing SSL_OP_CIPHER_SERVER_PREFERENCE?
--
nosy: +pitrou
type: security -> enhancement
versions: -Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.4
___
Python
Antoine Pitrou added the comment:
So, there are two things here:
- allow to disable compression (it's enabled by default AFAICT) using the
SSL_OP_NO_COMPRESSION flag
- allow to query compression status on SSL sockets using the
SSL_get_current_compression() API
--
nosy: +pitrou
Antoine Pitrou added the comment:
> If you want we can open a discussion within Tor Project to have a
> "rationale method" to define a set of "default ciphers" considering
> the ration of security/performance/compatibility.
Why don't you simple define you
Antoine Pitrou added the comment:
As I said, I don't think maintaining an explicit list of ciphers ourselves is
reasonable, since there are no crypto experts (AFAICT) amongst the Python core
developers.
Also, maintaining an explicit list of ciphers means people wouldn'
Antoine Pitrou added the comment:
Actually, it seems we want 'HIGH:!aNULL:!eNULL' to avoid non-encrypted and
non-authenticated ciphers.
> That way (but this is an approach to be discussed) we will pick-up
> a set of widely secure ciphers
Please read my message above and under
Antoine Pitrou added the comment:
Here is a possible patch for 3.2.
Probably needs a doc addition as well.
--
keywords: +patch
stage: needs patch -> patch review
versions: +Python 2.7
Added file: http://bugs.python.org/file24051/default_ciphers.pa
Antoine Pitrou added the comment:
> - Disable SSLv2
It should be disabled automatically since the SSLv2 cipher suites are not part
of "HIGH": see
http://www.openssl.org/docs/apps/ciphers.html#SSL_v2_0_cipher_suites_
> - Enable ECC/ECDHE by default
> - Enable DH/DHE by
Antoine Pitrou added the comment:
The new option is now committed in 3.3. Thanks for the report!
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Antoine Pitrou added the comment:
> We must disable SSLv1 with !SSLv2, for example i am using just now
> 'HIGH:!aNULL:!eNULL:!SSLv2:@STRENGTH' .
Ok, thanks for the investigation. I think "HIGH:!aNULL:!eNULL:!SSLv2" is
sufficient.
--
Antoine Pitrou added the comment:
> MD5 has been disabled for SSL use due to it's weakness by:
Apparently MD5 is already disabled by "HIGH:!SSLv2".
--
___
Python tracker
<http://bugs.
501 - 600 of 16792 matches
Mail list logo
