On Wed, Apr 8, 2009 at 7:13 AM, John Barham wrote:
> If you play around a bit it becomes clear that what set.pop() returns
> is independent of the insertion order:
It might look like that, but I don't think this is
true in general (at least, with the current implementation):
>>> foo = set([1, 65
Tennessee Leeuwenburg wrote:
> Now, I know that sets aren't ordered, but...
>
> foo = set([1,2,3,4,5])
> bar = [1,2,3,4,5]
>
> foo.pop() will reliably return 1
> while bar.pop() will return 5
>
> discuss :)
As designed.
If you play around a bit it becomes clear that what set.pop() returns
is inde
On Wed, Apr 8, 2009 at 12:09 AM, Michele Simionato
wrote:
> On Tue, Apr 7, 2009 at 11:04 PM, Terry Reedy wrote:
>>
>> This probably should have gone to the python-ideas list. In any case, I
>> think it needs to start with a clear offer from Michele (directly or relayed
>> by you) to contribute i
-On [20090408 05:24], Tennessee Leeuwenburg (tleeuwenb...@gmail.com) wrote:
>It seems like the bug relates only to an older version of a 'weird'
>operating system and could perhaps be left unfixed without causing
>anyone any problems.
Being one of the FreeBSD guys I'll throw peanuts at you. :P
I
[Tennessee Leeuwenburg ]
Now, I know that sets aren't ordered, but...
foo = set([1,2,3,4,5])
bar = [1,2,3,4,5]
foo.pop() will reliably return 1
while bar.pop() will return 5
discuss :)
If that's what you need:
http://code.activestate.com/recipes/576694/
Raymond
__
Now, I know that sets aren't ordered, but...
foo = set([1,2,3,4,5])
bar = [1,2,3,4,5]
foo.pop() will reliably return 1
while bar.pop() will return 5
discuss :)
Cheers,
-T
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailma
Tennessee Leeuwenburg writes:
> I'd agree with that. I just wonder whether it's necessary to create another
> issue, or whether the issue can be marked as 'fixed' without opening the new
> issue.
Opening a new issue has the effect of running a poll of those who
watch such issues on the tracker
On Tue, Apr 7, 2009 at 11:04 PM, Terry Reedy wrote:
>
> This probably should have gone to the python-ideas list. In any case, I
> think it needs to start with a clear offer from Michele (directly or relayed
> by you) to contribute it to the PSF with the usual conditions.
I have no problem to con
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I'm happy to announce the release of Python 2.6.2 candidate 1. This
release contains dozens of bug fixes since Python 2.6.1. Please see
the NEWS file for a detailed list of changes.
Barring unforeseen problems, Python 2.6.2 final will be relea
On Wed, Apr 8, 2009 at 1:14 PM, Guilherme Polo wrote:
> On Tue, Apr 7, 2009 at 11:54 PM, Tennessee Leeuwenburg
> wrote:
> > This issue has been largely resolved, but there is an outstanding bug
> where
> > the (reviewed and committed) solution does not work on certain versions
> of
> > FreeBSD (
On Tue, Apr 7, 2009 at 11:54 PM, Tennessee Leeuwenburg
wrote:
> This issue has been largely resolved, but there is an outstanding bug where
> the (reviewed and committed) solution does not work on certain versions of
> FreeBSD (broken in 6.3, working in 7+). Do we have a list of 'supported
> platf
Did you read the post until the end? The OP is asking a question
related to a very low level detail of dict implementation and making
an offer to write a patch that could speed-up dict.setdefault() in
core CPython... IMHO, a poll on python-dev do makes sense...
On Tue, Apr 7, 2009 at 1:34 PM, Aahz
This issue has been largely resolved, but there is an outstanding bug where
the (reviewed and committed) solution does not work on certain versions of
FreeBSD (broken in 6.3, working in 7+). Do we have a list of 'supported
platforms', and is FreeBSD 6.3 in it?
What's the policy with regards to sup
On Wed, Apr 8, 2009 at 7:54 AM, Alexander Neundorf
wrote:
> On Wed, Apr 8, 2009 at 12:43 AM, Greg Ewing
> wrote:
>> David Cournapeau wrote:
>>>
>>> Having a full
>>> fledged language for complex builds is nice, I think most familiar
>>> with complex makefiles would agree with this.
>>
>> Yes, pe
On Wed, Apr 8, 2009 at 6:42 AM, Alexander Neundorf
wrote:
> What options ?
Compilation options. If you build an extension with distutils, the
extension is built with the same flags as the ones used by python, the
options are taken from distutils.sysconfig (except for MS compilers,
which has its
Alexander Neundorf wrote:
My experience is that people don't need
general computation in their build process.
> ...
CMake supports now more general purpose programming features than it
did 2 years ago, e.g. it has now functions with local variables, it
can do simple math, regexps and other thin
Sadly, my work firewall/proxy often handles things badly, so I can't
actually tell. Is bugs.python.org accepting changes at the moment (I'm
trying to update the Stage of an issue)?
Cheers,
-T
--
--
Tennessee Leeuwenburg
http://myownhat.blogspot.com
On Wed, Apr 8, 2009 at 12:43 AM, Greg Ewing wrote:
> David Cournapeau wrote:
>>
>> Having a full
>> fledged language for complex builds is nice, I think most familiar
>> with complex makefiles would agree with this.
>
> Yes, people will still need general computation in their
> build process from
David Cournapeau wrote:
Having a full
fledged language for complex builds is nice, I think most familiar
with complex makefiles would agree with this.
Yes, people will still need general computation in their
build process from time to time whether the build tool
they're using supports it or not
I know the subject of external dependencies came up here in the discussion
about Mercurial. I just saw this on the Mercurial mailing list. Perhaps it
will be of interest to our hg mavens.
Skip
--- Begin Message ---
Hi,
I've recently cloned the deps extension, originally developed by Aleix
Con
On Tue, Apr 7, 2009 at 3:23 PM, David Cournapeau wrote:
> On Tue, Apr 7, 2009 at 10:08 PM, Alexander Neundorf
> wrote:
>
>>
>> What is involved in building python extensions ? Can you please explain ?
>
> Not much: at the core, a python extension is nothing more than a
> dynamically loaded librar
Alexandru Moșoi wrote:
From: "Cesare Di Mauro"
So if Python will generate
LOAD_CONST 1
LOAD_CONST 2
BINARY_ADD
the constant folding code will simply replace them with a single
LOAD_CONST 3
When working with such kind of optimizations, the temptation is to
apply them at any sit
Cesare Di Mauro wrote:
On Tue, Apr 7, 2009 07:22PM, Guido van Rossum wrote:
In my experience it's better to discover a bug at compile time rather
than
at running time.
That's my point though, which you seem to be ignoring: if the user
explicitly writes "1/0" it is not likely to be a bug. That's
Daniel Fetchinson wrote:
The decorator module [1] written by Michele Simionato is a very useful
tool for maintaining function signatures while applying a decorator.
Many different projects implement their own versions of the same
functionality, for example turbogears has its own utility for this,
One issue that the PEP needs to address is what to do with the files
that use svn (really, CVS) keywords, and what should happen to
sys.subversion. Along with it goes the question what sys.version
should say.
It probably would be good if somebody could produce a patch that
can be applied to a merc
On 7 Apr 2009, at 11:59, Alexandru Moșoi wrote:
Not necessarily. For example C/C++ doesn't define the order of the
operations inside an expression (and AFAIK neither Python) and
therefore folding 2 * 3 is OK whether b is an integer or an arbitrary
object with mul operator overloaded. Moreover one
> Ben is correct: you can't assume that contributors will have both a
> first name and a last name, or that a first name and last name is
> sufficient to legally identify them. Those from Spanish and Portuguese
> cultures usually have two family names as well as a personal name;
> people from I
Greg Ewing a écrit :
Firephoenix wrote:
I basically agreed with renaming the next() method to __next__(), so
as to follow the naming of other similar methods (__iter__() etc.).
But I noticed then that all the other methods of the generator had
stayed the same (send, throw, close...)
Keep in
> Such a policy would then translate to a dead end for Python 2.x
> based applications.
2.x based applications *are* in a dead end, with the only exit
being portage to 3.x.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.py
On Tue, Apr 7, 2009 at 8:59 PM, Alexandru Moșoi wrote:
> Not necessarily. For example C/C++ doesn't define the order of the
> operations inside an expression (and AFAIK neither Python) and
> therefore folding 2 * 3 is OK whether b is an integer or an arbitrary
> object with mul operator overloade
> From: "Cesare Di Mauro"
> So if Python will generate
>
> LOAD_CONST 1
> LOAD_CONST 2
> BINARY_ADD
>
> the constant folding code will simply replace them with a single
>
> LOAD_CONST 3
>
> When working with such kind of optimizations, the temptation is to
> apply them at any situat
Dirkjan Ochtman wrote:
> One of the nicer features of Mercurial/DVCSs, in my experience, is
> that non-committers get to keep the credit on their patches. That
> means that it's impossible to enforce a policy more extensive than
> some basic checks (such as the format above). Unless we keep a list
On Tue, Apr 7, 2009 at 20:25, Daniel (ajax) Diniz wrote:
> BTW, keep in mind some people will prefer to submit diff-generated,
> non-hg patches. IMO, this use case should be supported before the
> rich-patch one.
Sure, that will be in the PEP as well (and it's quite simple).
Cheers,
Dirkjan
__
On Tue, Apr 7, 2009 07:22PM, Guido van Rossum wrote:
>> In my experience it's better to discover a bug at compile time rather
>> than
>> at running time.
>
> That's my point though, which you seem to be ignoring: if the user
> explicitly writes "1/0" it is not likely to be a bug. That's very
> diff
At 04:58 PM 4/7/2009 +0200, M.-A. Lemburg wrote:
On 2009-04-07 16:05, P.J. Eby wrote:
> At 02:30 PM 4/7/2009 +0200, M.-A. Lemburg wrote:
>> >> Wouldn't it be better to stick with a simpler approach and look for
>> >> "__pkg__.py" files to detect namespace packages using that O(1)
>> check ?
>> >
On Wed, Apr 8, 2009 at 2:24 AM, Heikki Toivonen
wrote:
> David Cournapeau wrote:
>> The hard (or rather time consuming) work is to do everything else that
>> distutils does related to the packaging. That's where scons/waf are
>> more interesting than cmake IMO, because you can "easily" give up thi
On Tue, Apr 7, 2009 at 9:46 AM, Cesare Di Mauro
wrote:
> On Tue, Apr 7, 2009 06:25PM, Guido van Rossum wrote:
>> Well I'm sorry Cesare but this is unacceptable. As Skip points out
>> there is plenty of code that relies on this.
>
> Guido, as I already said, in the final code the normal Python beha
On Tue, Apr 7, 2009 06:25PM, Guido van Rossum wrote:
> Well I'm sorry Cesare but this is unacceptable. As Skip points out
> there is plenty of code that relies on this.
Guido, as I already said, in the final code the normal Python behaviour
will be kept, and the stricter one will be enabled solely
On Mon, Apr 06, 2009, Dan Schult wrote:
>
> I'm trying to write a C extension which is a subclass of dict.
> I want to do something like a setdefault() but with a single lookup.
python-dev is for core development, not for questions about using Python.
Please use comp.lang.python or the capi-sig li
Well I'm sorry Cesare but this is unacceptable. As Skip points out
there is plenty of code that relies on this. Also, consider what
"problem" you are trying to solve here. What is the benefit to the
user of moving this error to compile time? I cannot see any.
--Guido
On Tue, Apr 7, 2009 at 8:19 A
On Tue, Apr 7, 2009 at 5:25 AM, M.-A. Lemburg wrote:
> On 2009-04-06 15:21, Jesse Noller wrote:
>> On Thu, Apr 2, 2009 at 4:33 PM, M.-A. Lemburg wrote:
>>> On 2009-04-02 17:32, Martin v. Löwis wrote:
I propose the following PEP for inclusion to Python 3.1.
>>> Thanks for picking this up.
>>>
On Tue, Apr 07, 2009, Mark Dickinson wrote:
>
> Executive summary (details and discussion points below)
> =
>
> Some time ago, Noam Raphael pointed out that for a float x,
> repr(x) can often be much shorter than it currently is, without
> sacrificing the property that eval(repr(x)
Mark Dickinson wrote:
One PyCon 2009 sprint later, Eric Smith and I have
produced the py3k-short-float-repr branch, which implements
short repr of floats and also does some major cleaning
up of the current float formatting functions.
We've gone for the {fast, correct} pairing.
We'd like to get th
It would have helped if I'd copied the list...
Sorry,
Paul.
2009/4/7 Paul Moore :
> 2009/4/7 Michael Foord :
>> Mark Dickinson wrote:
>>>
>>> [snip...]
>>> Discussion points
>>> =
>>>
>>> (1) Any objections to including this into py3k? If there's
>>> controversy, then I guess we
Mark Dickinson wrote:
[snip...]
Discussion points
=
(1) Any objections to including this into py3k? If there's
controversy, then I guess we'll need a PEP.
Big +1
(2) Should other Python implementations (Jython,
IronPython, etc.) be expected to use short float repr, or
On Tue, Apr 7, 2009 at 15:05, KDr2 wrote:
> I need an CPyAN.
On the lighter side of things: That would be pronounced "spy-ann",
which mean "the vomit" is swedish. Do you still want it? :-D
--
Lennart Regebro: Pythonista, Barista, Notsotrista.
http://regebro.wordpress.com/
+33 661 58 14 64
On Tue, Apr 7, 2009 at 11:58 PM, M.-A. Lemburg wrote:
>>
>> This means your proposal actually doesn't add any benefit over the
>> status quo, where you can have an __init__.py that does nothing but
>> declare the package a namespace. We already have that now, and it
>> doesn't need a new filenam
In data 07 aprile 2009 alle ore 17:19:25, ha scritto:
>
> Cesare> The only difference at this time is regards invalid operations,
> Cesare> which will raise exceptions at compile time, not at running
> Cesare> time.
>
> Cesare> So if you write:
>
> Cesare> a = 1 / 0
>
> Ce
>> I don't know thing one about cmake, but if it's good for the goose
>> (building Python proper) would it be good for the gander (building
>> extensions)?
Antoine> African or European?
I was thinking Canadian...
Skip
___
Python-Dev ma
Cesare> The only difference at this time is regards invalid operations,
Cesare> which will raise exceptions at compile time, not at running
Cesare> time.
Cesare> So if you write:
Cesare> a = 1 / 0
Cesare> an exception will be raised at compile time.
I think I have to ca
Hi,
I've added the issue to tracker. http://bugs.python.org/issue5717
--anatoly t.
On Sun, Dec 21, 2008 at 12:19 PM, Yinon Ehrlich wrote:
> Hi,
>
> just saw that os.defpath for Windows is defined as
> Lib/ntpath.py:30:defpath = '.;C:\\bin'
>
> Most Windows machines I saw has no c:\bin di
On 3 Apr, 2009, at 0:57, Guido van Rossum wrote:
The primary use case is some kind of trap on assignment. While this
cannot cover all cases, most non-local variables are stored in dicts.
List mutations are not in the same league, as use case.
I have a slightly different use-case than a debu
Greg Ewing wrote:
Steve Holden wrote:
Isn't it strange how nobody every complained about the significance of
whitespace in makefiles: only the fact that leading tabs were required
rather than just-any-old whitespace.
Make doesn't care how *much* whitespace there
is, though, only whether it's
On 2009-04-07 16:05, P.J. Eby wrote:
> At 02:30 PM 4/7/2009 +0200, M.-A. Lemburg wrote:
>> >> Wouldn't it be better to stick with a simpler approach and look for
>> >> "__pkg__.py" files to detect namespace packages using that O(1)
>> check ?
>> >
>> > Again - this wouldn't be O(1). More importantl
Executive summary (details and discussion points below)
=
Some time ago, Noam Raphael pointed out that for a float x,
repr(x) can often be much shorter than it currently is, without
sacrificing the property that eval(repr(x)) == x, and proposed
changing Python accordingly. See
ht
On Tue, Apr 07, 2009, Dirkjan Ochtman wrote:
> On Tue, Apr 7, 2009 at 16:29, Aahz wrote:
>>
>> What you apparently are unaware of is that "Aahz" is in fact my full
>> legal name. (Which was clearly the point of Steven's post since he knows
>> that Teller also has only one legal name -- it's not c
On Tue, Apr 7, 2009 at 16:29, Aahz wrote:
> What you apparently are unaware of is that "Aahz" is in fact my full
> legal name. (Which was clearly the point of Steven's post since he knows
> that Teller also has only one legal name -- it's not common, but we do
> exist.)
Ah, sorry about that. But
On Tue, Apr 07, 2009, Dirkjan Ochtman wrote:
> On Tue, Apr 7, 2009 at 13:42, Steven D'Aprano wrote:
>>
>> Perhaps you should ask Aahz what he thinks about being forced to provide
>> two names before being allowed to contribute.
Thanks for speaking up! I'm not sure I would have noticed the
implic
At 02:30 PM 4/7/2009 +0200, M.-A. Lemburg wrote:
>> Wouldn't it be better to stick with a simpler approach and look for
>> "__pkg__.py" files to detect namespace packages using that O(1) check ?
>
> Again - this wouldn't be O(1). More importantly, it breaks system
> packages, which now again have
On Tue, Apr 7, 2009 at 10:08 PM, Alexander Neundorf
wrote:
>
> What is involved in building python extensions ? Can you please explain ?
Not much: at the core, a python extension is nothing more than a
dynamically loaded library + a couple of options. One choice is
whether to take options from d
On Tue, Apr 7, 2009 at 2:14 PM, wrote:
>
>Ondrej> ... while scons and other Python solutions imho encourage to
>Ondrej> write full Python programs, which imho is a disadvantage for the
>Ondrej> build system, as then every build system is nonstandard.
I fully agree here.
> Hmmm... L
On Tue, Apr 7, 2009 at 9:14 PM, wrote:
>
> Ondrej> ... while scons and other Python solutions imho encourage to
> Ondrej> write full Python programs, which imho is a disadvantage for the
> Ondrej> build system, as then every build system is nonstandard.
>
> Hmmm... Like distutils setup
Neal Becker gmail.com> writes:
>
> 2. Various utilities to provide query package management.
>- easy_install --list (list files installed)
"yolk" will tell you that.
http://pypi.python.org/pypi/yolk
Regards
Antoine.
___
Python-Dev mailing list
On Tue, Apr 7, 2009 at 9:02 AM, Neal Becker wrote:
> 1. easy_remove!
>
> 2. Various utilities to provide query package management.
> - easy_install --list (list files installed)
This discussion should happen on the distutils-sig list; not python-dev
_
I need an CPyAN.
--
Best Regards,
-- KDr2, at x-macro.com.
On Tue, Apr 7, 2009 at 9:02 PM, Neal Becker wrote:
> 1. easy_remove!
>
> 2. Various utilities to provide query package management.
> - easy_install --list (list files installed)
>
>
> __
1. easy_remove!
2. Various utilities to provide query package management.
- easy_install --list (list files installed)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.pyt
pobox.com> writes:
>
> I don't know thing one about cmake, but if it's good for the goose (building
> Python proper) would it be good for the gander (building extensions)?
African or European?
___
Python-Dev mailing list
Python-Dev@python.org
http:/
[Resent due to a python.org mail server problem]
On 2009-04-03 22:07, Martin v. Löwis wrote:
>> I'd like to extend the proposal to Python 2.7 and later.
>
> I don't object, but I also don't want to propose this, so
> I added it to the discussion.
>
> My (and perhaps other people's) concern is th
Ondrej> ... while scons and other Python solutions imho encourage to
Ondrej> write full Python programs, which imho is a disadvantage for the
Ondrej> build system, as then every build system is nonstandard.
Hmmm... Like distutils setup scripts?
I don't know thing one about cmake, bu
On 2009-04-06 15:21, Jesse Noller wrote:
> On Thu, Apr 2, 2009 at 4:33 PM, M.-A. Lemburg wrote:
>> On 2009-04-02 17:32, Martin v. Löwis wrote:
>>> I propose the following PEP for inclusion to Python 3.1.
>> Thanks for picking this up.
>>
>> I'd like to extend the proposal to Python 2.7 and later.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Nick Coghlan wrote:
> Tres Seaver wrote:
>> I don't think either of these classes should be subject to a deprecation
>> warning for a feature they never used or depended on.
>
> Agreed. Could you raise a tracker issue for the spurious warnings? (I
> b
On 2009-04-03 02:44, P.J. Eby wrote:
> At 10:33 PM 4/2/2009 +0200, M.-A. Lemburg wrote:
>> Alternative Approach:
>> -
>>
>> Wouldn't it be better to stick with a simpler approach and look for
>> "__pkg__.py" files to detect namespace packages using that O(1) check ?
>
>> One of
On Tue, Apr 7, 2009 at 13:42, Steven D'Aprano wrote:
> Perhaps you should ask Aahz what he thinks about being forced to provide
> two names before being allowed to contribute.
Huh? The contributor's agreement list would presumably include real
names only (so Aahz is out of luck), but the names wo
On Tue, 7 Apr 2009 04:30:10 pm Dirkjan Ochtman wrote:
> On Tue, Apr 7, 2009 at 08:25, Ben Finney
wrote:
> > Remembering, of course, that full names don't follow any template
> > (especially not first-name last-name). The person's full name must
> > be treated as free-form text, since there's no f
2009/4/7 Cesare Di Mauro :
> The principle that I followed on doing constant folding was: "do what Python
> will do without constant folding enabled".
>
> So if Python will generate
>
> LOAD_CONST 1
> LOAD_CONST 2
> BINARY_ADD
>
> the constant folding code will simply replace them with a
Thomas Wouters schrieb:
>
> Anyone able to look into this and fix it? Having all of the normal
> entrypoints for documentation broken is rather inconvenient for users :-)
A rebuild should do the trick, I'll fix this ASAP.
Georg
___
Python-Dev mailing
On 07/04/2009, at 7:27 AM, Guido van Rossum wrote:
On Mon, Apr 6, 2009 at 7:28 AM, Cesare Di Mauro
wrote:
The Language Reference says nothing about the effects of code
optimizations.
I think it's a very good thing, because we can do some work here
with constant
folding.
Unfortunately the
On Apr 07, 2009 at 02:10AM, Steven D'Aprano wrote:
> On the other hand, I'm with Guido when he wrote "it is certainly not
> right to choose speed over correctness". This is especially a problem
> for floating point optimizations, and I urge Cesare to be conservative
> in any f.p. optimizations he
78 matches
Mail list logo
