your "still TODO but no time"
items. Meanwhile I will take a closer look @ http://www.python.org/dev/intro
and see where/if I can roll up my sleeves and lend a hand.
Thanks for the reply & info and I look forward to contributing!
Mart :)
On 2010-06-16, at 9:19 AM, Nick Coghl
Hi,
I have worked 10 years at Adobe Systems as a Release Developer for the
LiveCycle ES team and am now employed as a Release Manager (for a team of one,
me ;) ) at Nuance Communications since last March. I have put lots of effort
to keep Python alive and well at Adobe by providing complete bu
On Wed, Nov 4, 2009 at 5:54 PM, Collin Winter wrote:
> Do note that the --track_memory option to perf.py imposes some
> overhead that interferes with the performance figures.
Thanks for the notice, without -m/--track_memory the deviation in
results is indeed much smaller.
> I'd recommend
> runni
11325: 51.32% larger
Mem max: 7776.000 -> 8676.000: 10.37% larger
Usage over time: http://tinyurl.com/yz96gw2
unpickle_list:
Min: 0.922200 -> 0.861167: 7.09% faster
Avg: 0.955964 -> 0.976829: 2.14% slower
Not significant
Stddev: 0.04374 -> 0.21061: 79.23% larger
Mem max: 6820.000
On Sun, Apr 19, 2009 at 2:06 AM, Nick Coghlan wrote:
> That said, I'm starting to wonder if an even better option may be to
> just drop the kwargs support from the function and require people to
> always supply a parameters dictionary. That would simplify the signature
> to the quite straightforwa
On Sat, Apr 18, 2009 at 3:41 PM, Nick Coghlan wrote:
> Yep - Guido has pointed out in a few different API design discussions
> that a boolean flag that is almost always set to a literal True or False
> is a good sign that there are two functions involved rather than just
> one. There are exception
On Mon, Apr 13, 2009 at 8:23 PM, Steven Bethard
wrote:
>
> On Mon, Apr 13, 2009 at 2:29 AM, Mart Sõmermaa wrote:
> >
> >
> > On Mon, Apr 13, 2009 at 12:56 AM, Antoine Pitrou
> > wrote:
> >>
> >> Mart Sõmermaa gmail.com> writes:
> >> &
On Mon, Apr 13, 2009 at 12:56 AM, Antoine Pitrou wrote:
> Mart Sõmermaa gmail.com> writes:
> >
> > Proposal: add add_query_params() for appending query parameters to an URL
> to
> urllib.parse and urlparse.
>
> Is there anything to /remove/ a query parameter?
I&#
On Sun, Apr 12, 2009 at 3:23 PM, Jacob Holm wrote:
> Hi Mart
>
>>>> add_query_params('http://example.com/a/b/c?a=b', b='d', foo='/bar')
>>'http://example.com/a/b/c?a=b&b=d&foo=%2Fbar <
>> http://example.com/a
The general consensus in python-ideas is that the following is needed, so I
bring it to python-dev to final discussions before I file a feature request
in bugs.python.org.
Proposal: add add_query_params() for appending query parameters to an URL to
urllib.parse and urlparse.
Implementation:
http:
On Sat, Mar 28, 2009 at 12:37 AM, Ben Finney <
bignose+hates-s...@benfinney.id.au >wrote:
> "Martin v. Löwis" writes:
>
> > I don't mind the setuptools implementation being used as a basis
> > (assuming it gets contributed), but *independently* I think a
> > specfication is needed what version st
> Instead of trying to parse some version string, distutils should
> require defining the version as tuple with well-defined entries -
> much like what we have in sys.version_info for Python.
>
> The developer can then still use whatever string format s/he wants.
>
> The version compare function wo
See http://wiki.python.org/moin/ApplicationInfrastructure , "Version
handling" below for a possible strict version API.
The page is relevant for the general packaging discussion as well, although
it's not fully fleshed out yet.
MS
On Fri, Mar 27, 2009 at 5:11 PM, "Martin v. Löwis" wrote:
> Corr
On Tue, Mar 10, 2009 at 3:57 PM, Michael Foord wrote:
> Is there something you don't like about this one:
> http://code.activestate.com/recipes/576529/
>
Yes -- it is not in the standard library. As I said, eventually all the
15,000 matches on Google Code need to update their code and copy that
s
__cmp__ used to provide a convenient way to make all ordering operators work
by defining a single method. For better or worse, it's gone in 3.0.
To provide total ordering without __cmp__ one has to implement all of
__lt__, __gt__, __le__, __ge__, __eq__ and __ne__. However, in all but a few
cases
On Tue, Jan 27, 2009 at 5:04 PM, Jesse Noller wrote:
> Hi Mart,
>
> This is a better discussion for the python-ideas list. That being
> said, there was a thread discussing this last year, see:
>
> http://mail.python.org/pipermail/python-dev/2008-October/083176.html
>
>
elved into the designs and considered their applicability to
Python?
Hoping-to-see-some-V8-and-Python-teams-collaboration-in-Mountain-View-ly
yours,
Mart Sõmermaa
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/
Brett Cannon wrote:
> The old-hands on python-dev know this is where I plug my import
> rewrite vaporware. It will be in 3.1, and as part of it there will be
> a new API for handling direct imports. Jacob Kaplan-Moss and I have
Sounds good. I can finally rest in peace :) . May I suggest
that y
> If __import__ was replaced with a version with NON compatible interface,
> "import x.y.z" would break.
But it is not. The proposed __import__(name, submodule=True) has
a compatible interface. All tests pass with
http://bugs.python.org/file12136/issue4438.diff .
As for the imp approach, I've al
Nick Coghlan wrote:
As Hrvoje has pointed out, 'sys' is part of the internal interpreter
machinery - it's there as soon as the interpreter starts. The import
call for it just grabs it out of the module cache and creates a
reference to it in the current namespace.
I understand that, but
Explici
The variant proposed by Hrvoje Niksic:
>>> __import__(modname)
>>> mod = sys.modules[modname]
looks more appealing, but comes with the drawback that sys has to be
imported for that purpose only.
That is not a real drawback, as "sys" will certainly be present in the
system, so the "importin
Nick Coghlan wrote:
i.e.
"from foo.bar import baz" >
= __import__('foo.bar', globals(), locals(), ['baz'], -1)
baz = .baz
When there are multiple names being imported or an 'as' clause is
involved, I hope the reasons for doing it this way become more obvious:
"from foo.bar import baz, bo
Python programmers need to dynamically load submodules instead of
top-level modules -- given a string with module hierarchy, e.g.
'foo.bar.baz', access to the tail module 'baz' is required instead
of 'foo'.
Currently, the common hack for that is to use
modname = 'foo.bar.baz' mod = __import__(m
When I looked through that list a week or so ago, I noticed that some
issues were obviously related to the Python distribution itself, but
others were appeared to be Python application problems.
I looked through the list now and weeded out irrelevant CVEs (by putting them
into
the ignore list
I created a script that parses the
http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=python
Python-related CVE list and classifies the CVEs as follows:
* "ok" -- CVE has references to bugs.python.org
* "warnings" -- CVE has references to Python SVN revisions
or an issue in bugs.python.org refers
Hello!
Does someone systematically track the CVE vulnerability list?
Ideally, Python security officers would have close collaboration with
whoever
manages CVE (like distribution security officers do), so that
* every CVE issue would have a corresponding ticket on Python bug tracker
(perhaps
26 matches
Mail list logo
