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
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
__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, 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
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
> 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
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
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 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
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 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 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 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
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 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
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
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
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
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
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
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:
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
> 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
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
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/
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
>
>
26 matches
Mail list logo
