Vinay Sajip wrote:
Nick Coghlan ncoghlan at gmail.com writes:
I'm starting to think that a converter between the two format
mini-languages may be the way to go though.
fmt_braces is meant to provide a superset of the capabilites of
fmt_percent, so a forward converter shouldn't be too hard.
Raymond Hettinger python at rcn.com writes:
We should get one written. ISTM, every %-formatting
string is directly translatable to an equivalent {}-formatting string.
I'm not sure you can always get equivalent output from the formatting, though.
For example:
%0#8x % 0x1234
'0x001234'
it's revews like this that makes me wonder if releasing open source is
a good idea:
no egg - worst seen ever, remove it from pypi or provide an egg
(jensens, 2009-10-05, 0 points)
/F
___
Python-Dev mailing list
Python-Dev@python.org
2009/10/5 Vinay Sajip vinay_sa...@yahoo.co.uk:
Raymond Hettinger python at rcn.com writes:
We should get one written. ISTM, every %-formatting
string is directly translatable to an equivalent {}-formatting string.
I'm not sure you can always get equivalent output from the formatting, though.
Vinay Sajip wrote:
Raymond Hettinger python at rcn.com writes:
We should get one written. ISTM, every %-formatting
string is directly translatable to an equivalent {}-formatting string.
I'm not sure you can always get equivalent output from the formatting, though.
For example:
%0#8x %
Fredrik Lundh fred...@pythonware.com writes:
it's revews like this that makes me wonder if releasing open source is
a good idea:
no egg - worst seen ever, remove it from pypi or provide an egg
(jensens, 2009-10-05, 0 points)
Heh. If harsh, uninformed responses make you wonder whether
MRAB python at mrabarnett.plus.com writes:
{0:#08x}.format(0x1234)
'0x001234'
Good call, but here's another case:
%#o % 0x1234
'011064'
I don't see how to automatically convert the %#o spec, though of course there
are ways of fudging it. The obvious conversion doesn't give the same value:
On Mon, Oct 05, 2009 at 10:43:22AM +0200, Fredrik Lundh wrote:
it's revews like this that makes me wonder if releasing open source is
a good idea:
no egg - worst seen ever, remove it from pypi or provide an egg
(jensens, 2009-10-05, 0 points)
Greetings effbot. :)
As you might already
Oh, it was just yet another Zope developer behaving like an ass. Why
am I not surprised?
/F
On Mon, Oct 5, 2009 at 10:43 AM, Fredrik Lundh fred...@pythonware.com wrote:
it's reviews like this that makes me wonder if releasing open source is
a good idea:
no egg - worst seen ever, remove it
Martin v. Löwis wrote:
That doesn't mean we have to have a transition plan *now*. Creating one
after Python 3.5 is released (i.e. in 2015 or so) might be sufficient.
To create a transition plan, you first need *consensus* that you
actually do want to transition. I don't think such consensus
On Mon, Oct 5, 2009 at 4:58 AM, Fredrik Lundh fred...@pythonware.com wrote:
Oh, it was just yet another Zope developer behaving like an ass. Why
am I not surprised?
Actually, most of us Zope developers prefer sdist packages, not eggs.
-Fred
--
Fred L. Drake, Jr.fdrake at gmail.com
Fredrik Lundh wrote:
Oh, it was just yet another Zope developer behaving like an ass. Why
am I not surprised?
Tarring an entire community for the actions of one twit is more than a
little unfair.
It's fine that you don't like eggs and it's fine that you don't want to
provide them. There's a
Fredrik Lundh wrote:
Oh, it was just yet another Zope developer behaving like an ass. Why
am I not surprised?
/F
On Mon, Oct 5, 2009 at 10:43 AM, Fredrik Lundh fred...@pythonware.com wrote:
it's reviews like this that makes me wonder if releasing open source is
a good idea:
no egg -
He's not the first one from the Zope community (whatever that is)
that's behaved this way on this specific topic. The problem here is
that a certain (marginal) user community decides to standardize on a
certain distribution model, and then goes off attacking people who've
released stuff *before*
Am Montag, den 05.10.2009, 13:07 +0200 schrieb Christian Heimes:
Fredrik Lundh wrote:
Oh, it was just yet another Zope developer behaving like an ass. Why
am I not surprised?
/F
On Mon, Oct 5, 2009 at 10:43 AM, Fredrik Lundh fred...@pythonware.com
wrote:
it's reviews like this
There has been some discussion on the distutils-sig list over the past
few days about a change to distutils released with 2.6.3 which
inadvertently causes a number (all?) packages with C extensions that use
setuptools/easy_install to fail during builds/installs with a rather
cryptic error
On Mon, Oct 5, 2009 at 2:06 PM, Ned Deily n...@acm.org wrote:
Assuming that distutils is not changed in a forthcoming 2.6.4
Since the changes made in Distutils were bug fixes that kept all public API
backward compatible, I don't see why this should be changed.
Setuptools development has been
Tarek Ziadé wrote:
I'm not proposing to debate the merits of all of the options here.
However, if a 2.6.4 release is to be pushed out quickly for other
reasons, a one-time window of opportunity would be available and it
would be prudent to at least consider the possibility of a distutils fix.
Ned Due to a change in distutils released with Python 2.6.3, packages
Ned that use setuptools (version 0.6c9, as of this writing), or the
Ned easy_install command, to build C extension modules fail ...
...
Ned Among the packages known to be affected include lxml,
Ned
On Mon, Oct 5, 2009 at 2:50 PM, s...@pobox.com wrote:
Ned Due to a change in distutils released with Python 2.6.3, packages
Ned that use setuptools (version 0.6c9, as of this writing), or the
Ned easy_install command, to build C extension modules fail ...
...
Ned Among the
On Mon, Oct 5, 2009 at 4:43 AM, Fredrik Lundh fred...@pythonware.com wrote:
it's revews like this that makes me wonder if releasing open source is
a good idea:
no egg - worst seen ever, remove it from pypi or provide an egg
(jensens, 2009-10-05, 0 points)
/F
Unfortunately; we're now
On Oct 5, 2009, at 8:22 AM, Tarek Ziadé wrote:
I'm not proposing to debate the merits of all of the options here.
However, if a 2.6.4 release is to be pushed out quickly for other
reasons, a one-time window of opportunity would be available and it
would be prudent to at least consider the
On Mon, Oct 5, 2009 at 6:26 AM, Jens W. Klein j...@bluedynamics.com wrote:
Am Montag, den 05.10.2009, 13:07 +0200 schrieb Christian Heimes:
Fredrik Lundh wrote:
Oh, it was just yet another Zope developer behaving like an ass. Why
am I not surprised?
On Mon, Oct 5, 2009 at 10:43 AM,
On Mon, Oct 5, 2009 at 3:32 PM, Barry Warsaw ba...@python.org wrote:
On Oct 5, 2009, at 8:22 AM, Tarek Ziadé wrote:
I'm not proposing to debate the merits of all of the options here.
However, if a 2.6.4 release is to be pushed out quickly for other
reasons, a one-time window of opportunity
Tarek Ziadé wrote:
Now I am astonished that we are talking about reverting changes in
Distutils that were done for bugfixes, for a third party package that
does monkey
patches on Distutils.
If this choice wins here, it means that setuptools and the stdlib are
tied together, and that the
On Oct 5, 2009, at 10:17 AM, Tarek Ziadé wrote:
If setuptools can be made to work with Python 2.6.3 /and/ earlier
versions
of Python 2.6.x, then it should be patched and an update released.
If not,
then perhaps we should revert the change in a quick Python 2.6.4.
It's technically
M.-A. Lemburg wrote:
Tarek Ziadé wrote:
Now I am astonished that we are talking about reverting changes in
Distutils that were done for bugfixes, for a third party package that
does monkey
patches on Distutils.
If this choice wins here, it means that setuptools and the stdlib are
tied
Tarek That's why we have forked and created Distribute, to provide bug
Tarek fixes.
I suspect you might need to publicize this a bit better. The first I heard
of Distribute or non-responsiveness of PJE regarding setuptools was this
thread. (I don't read comp.lang.python anymore. I do
On Mon, Oct 5, 2009 at 9:32 AM, Barry Warsaw ba...@python.org wrote:
If, as I hope, the answer to that is yes, then I strongly support
releasing a fixed setuptools instead of reverting the change to Python.
How do your propose to get the author of setuptools to release a new
version?
--
On Mon, Oct 5, 2009 at 4:32 PM, Barry Warsaw ba...@python.org wrote:
On Oct 5, 2009, at 10:17 AM, Tarek Ziadé wrote:
If setuptools can be made to work with Python 2.6.3 /and/ earlier
versions
of Python 2.6.x, then it should be patched and an update released. If
not,
then perhaps we should
On Mon, Oct 5, 2009 at 4:27 PM, M.-A. Lemburg m...@egenix.com wrote:
Tarek Ziadé wrote:
Now I am astonished that we are talking about reverting changes in
Distutils that were done for bugfixes, for a third party package that
does monkey
patches on Distutils.
If this choice wins here, it
On Mon, Oct 5, 2009 at 4:40 PM, s...@pobox.com wrote:
Tarek That's why we have forked and created Distribute, to provide bug
Tarek fixes.
I suspect you might need to publicize this a bit better. The first I heard
of Distribute or non-responsiveness of PJE regarding setuptools was
Senthil Kumaran wrote:
On Mon, Oct 05, 2009 at 10:43:22AM +0200, Fredrik Lundh wrote:
it's revews like this that makes me wonder if releasing open source is
a good idea:
no egg - worst seen ever, remove it from pypi or provide an egg
(jensens, 2009-10-05, 0 points)
Greetings effbot. :)
Tarek Ziadé wrote:
On Mon, Oct 5, 2009 at 4:27 PM, M.-A. Lemburg m...@egenix.com wrote:
Tarek Ziadé wrote:
Now I am astonished that we are talking about reverting changes in
Distutils that were done for bugfixes, for a third party package that
does monkey
patches on Distutils.
If this
\ I hate calling methods on string literals, I think it looks very odd
to have code like this:
Displaying {0} of {1} revisions.format(x, y)
Ugh! Good point.
This objection was made years ago when we introduced
separator.join(list_of_things), and I don't think ignoring it has
caused any
On Mon, Oct 5, 2009 at 5:26 PM, M.-A. Lemburg m...@egenix.com wrote:
Tarek Ziadé wrote:
On Mon, Oct 5, 2009 at 4:27 PM, M.-A. Lemburg m...@egenix.com wrote:
Tarek Ziadé wrote:
Now I am astonished that we are talking about reverting changes in
Distutils that were done for bugfixes, for a third
On Oct 5, 2009, at 10:50 AM, Tarek Ziadé wrote:
If, as I hope, the answer to that is yes, then I strongly support
releasing a fixed setuptools instead of reverting the change to
Python.
Yes it does.
Excellent, thanks.
The fix makes sure build_ext.get_ext_filename still works as it is
On Oct 5, 2009, at 10:50 AM, Daniel Stutzbach wrote:
On Mon, Oct 5, 2009 at 9:32 AM, Barry Warsaw ba...@python.org wrote:
If, as I hope, the answer to that is yes, then I strongly support
releasing a fixed setuptools instead of reverting the change to
Python.
How do your propose to get
Jesse Noller schrieb:
On Mon, Oct 5, 2009 at 4:43 AM, Fredrik Lundh fred...@pythonware.com wrote:
it's revews like this that makes me wonder if releasing open source is
a good idea:
no egg - worst seen ever, remove it from pypi or provide an egg
(jensens, 2009-10-05, 0 points)
/F
-On [20091005 17:45], Barry Warsaw (ba...@python.org) wrote:
2) PJE releases a new version of setuptools that fixes this problem.
Will all due respect to PJE, but I sincerely doubt this will happen. There's
still a bunch of outstanding patches over at the setuptools tracker,
including SVN 1.x
Tarek No you didn't miss it. That's probably my fault because the only
Tarek places I publicize about it are my blog (indexed in planet
Tarek python) and the distutils-SIG.
Bloggers beware!!! Not everyone reads blogs. (I don't unless someone calls
my attention to something of
Hello,
Now I am astonished that we are talking about reverting changes in
Distutils that were done for bugfixes, for a third party package that
does monkey
patches on Distutils.
I think we should avoid any questions of responsability here (besides, it is
quite clear that you, Tarek, are not
On Mon, Oct 5, 2009 at 6:44 PM, Antoine Pitrou solip...@pitrou.net wrote:
The only question is, given that 2.6.x is supposed to be a bug-fix branch, do
we
want to fix that incompatibility with a widely deployed existing piece of
software? Whether or not the incompatibility is legitimate
Tarek Ziadé writes:
Maybe I should blog a summary of the situation and post it to
python annoucement as well.
Please don't. It's unlikely to do anything except incite a lot of
flames.
___
Python-Dev mailing list
Python-Dev@python.org
Tarek Ziadé wrote:
On Mon, Oct 5, 2009 at 6:44 PM, Antoine Pitrou solip...@pitrou.net wrote:
The only question is, given that 2.6.x is supposed to be a bug-fix branch,
do we
want to fix that incompatibility with a widely deployed existing piece of
software? Whether or not the
On Mon, Oct 5, 2009 at 7:06 PM, M.-A. Lemburg m...@egenix.com wrote:
Tarek Ziadé wrote:
On Mon, Oct 5, 2009 at 6:44 PM, Antoine Pitrou solip...@pitrou.net wrote:
The only question is, given that 2.6.x is supposed to be a bug-fix branch,
do we
want to fix that incompatibility with a widely
On Mon, Oct 5, 2009 at 12:00 PM, Georg Brandl g.bra...@gmx.net wrote:
Jesse Noller schrieb:
On Mon, Oct 5, 2009 at 4:43 AM, Fredrik Lundh fred...@pythonware.com wrote:
it's revews like this that makes me wonder if releasing open source is
a good idea:
no egg - worst seen ever, remove it
Dne 20.9.2009 18:42, Antoine Pitrou napsal(a):
Le Sun, 20 Sep 2009 10:33:23 -0600, Zooko O'Whielacronx a écrit :
By the way, I was investigating this, and discovered an issue on the
Mandriva tracker which suggests that they intend to switch to UCS4 in
the next release in order to avoid
On Mon, Oct 5, 2009 at 10:38 AM, Jesse Noller jnol...@gmail.com wrote:
On Mon, Oct 5, 2009 at 12:00 PM, Georg Brandl g.bra...@gmx.net wrote:
Jesse Noller schrieb:
On Mon, Oct 5, 2009 at 4:43 AM, Fredrik Lundh fred...@pythonware.com
wrote:
it's revews like this that makes me wonder if
On Mon, Oct 5, 2009 at 1:54 PM, Guido van Rossum gu...@python.org wrote:
User ratings and comments are the
future for app store style sites such as PyPI
Interestingly, I consider sites like PyPI as developer resources
rather than the more end-user-centric App Store sites.
While I don't
Interested in the recent threads about % and str.format(), I wrote a
little Python 3 script that converts % format strings to format
strings compatible with str.format(). I invite you to try it out. The
code is at https://code.launchpad.net/~gutworth/+junk/mod2format (That
means you can do bzr
On Oct 5, 2009, at 4:59 AM, Ben Finney wrote:
Fredrik Lundh fred...@pythonware.com writes:
it's revews like this that makes me wonder if releasing open source
is
a good idea:
no egg - worst seen ever, remove it from pypi or provide an egg
(jensens, 2009-10-05, 0 points)
Heh. If harsh,
Le lundi 05 octobre 2009 à 19:18 +0200, Jan Matejek a écrit :
I
don't see what is bad about improving compatibility in a place where the
setting doesn't hurt one way or the other.
I can't speak for Mandriva, but I'm sure they care more about not
breaking user installs when they upgrade to
On Mon, Oct 5, 2009 at 1:54 PM, Guido van Rossum gu...@python.org wrote:
On Mon, Oct 5, 2009 at 10:38 AM, Jesse Noller jnol...@gmail.com wrote:
On Mon, Oct 5, 2009 at 12:00 PM, Georg Brandl g.bra...@gmx.net wrote:
Jesse Noller schrieb:
On Mon, Oct 5, 2009 at 4:43 AM, Fredrik Lundh
On Mon, Oct 5, 2009 at 1:21 PM, Jesse Noller jnol...@gmail.com wrote:
On Mon, Oct 5, 2009 at 1:54 PM, Guido van Rossum gu...@python.org wrote:
[...]
User ratings and comments are the
future for app store style sites such as PyPI, and spam
unfortunately comes with the terrain. There are
At 01:26 PM 10/5/2009 +0200, Jens W. Klein wrote:
And as far as I understand PIL is not the
problem, but the packaging/ setuptools. For the records: PIL is a great
piece of software and I dont want to miss it.
Actually, the problem is that the package is called PIL in Pypi,
but the actual
At 02:22 PM 10/5/2009 +0200, Tarek Ziadé wrote:
Setuptools development has been discontinued for a year, and does
patches on Distutils code. Some of these patches are sensitive to any change
made on Distutils, wether those changes are internal or not.
Setuptools is also not the only thing out
At 04:17 PM 10/5/2009 +0200, Tarek Ziadé wrote:
Now I am astonished that we are talking about reverting changes in
Distutils that were done for bugfixes, for a third party package that
does monkey patches on Distutils.
Subclassing is not monkeypatching, so if you consider the above to be
a
On Mon, Oct 5, 2009 at 8:48 PM, P.J. Eby p...@telecommunity.com wrote:
names for the same thing. (I'm guessing that PIL was registered on PyPI
manually, before the setup.py register command existed. Heck, it was
probably being distributed before the distutils even existed, and indeed
before
On Mon, Oct 5, 2009 at 08:44, Barry Warsaw ba...@python.org wrote:
On Oct 5, 2009, at 10:50 AM, Tarek Ziadé wrote:
If, as I hope, the answer to that is yes, then I strongly support
releasing a fixed setuptools instead of reverting the change to Python.
Yes it does.
Excellent, thanks.
Brett Cannon wrote:
On Mon, Oct 5, 2009 at 08:44, Barry Warsaw ba...@python.org
mailto:ba...@python.org wrote:
On Oct 5, 2009, at 10:50 AM, Tarek Ziadé wrote:
If, as I hope, the answer to that is yes, then I
strongly support
releasing a fixed
Doug Hellmann wrote:
On Oct 5, 2009, at 4:59 AM, Ben Finney wrote:
If you *want* to respond, you can politely direct them to
URL:http://docs.python.org/install/ where they can learn how to
install Python distributions — no mention of eggs at all.
Package owners are not allowed to comment on
Fred Drake wrote:
On Mon, Oct 5, 2009 at 1:54 PM, Guido van Rossum gu...@python.org wrote:
User ratings and comments are the
future for app store style sites such as PyPI
Interestingly, I consider sites like PyPI as developer resources
rather than the more end-user-centric App Store sites.
Barry Warsaw wrote:
On Oct 4, 2009, at 4:11 AM, Nick Coghlan wrote:
Barry Warsaw wrote:
I also don't think this is a case of anti-TOOWTDI. For most situations
{}-strings are great (IMO), but in the specific translation domain, I
suspect $-strings are still better.
I agree that keeping
On Oct 5, 2009, at 2:21 PM, Brett Cannon wrote:
I should also mention this bug was not unknown. I discovered it
after Distribute 0.6 was released as I always run cutting edge
interpreters. Never bothered to report it until Distribute 0.6.1 was
released which Tarek fixed in less than a week.
On Oct 5, 2009, at 4:41 PM, Nick Coghlan wrote:
Oh, I see what you meant now - you were pointing out that lazy
formatting APIs (such as logging) already don't work properly for
alternative formatting mechanisms (such as string.Template).
Yep.
(Although printing to a String IO doesn't seem
On Mon, Oct 5, 2009 at 4:24 PM, Nick Coghlan ncogh...@gmail.com wrote:
When it comes to comments and recommendations for selecting software
packages, developers *are* the end users :)
Yes, most certainly. But developers as consumers are very different
from application users as consumers, which
My question was less about the political aspects than the technical aspects.
I gather you're saying that the fix to setuptools will make it work in
2.6.3 without inadvertently breaking it for 2.6.2, 2.6.1, and 2.6.0, right?
Have you tried the fix in those older versions to be sure?
If, as
On Mon, Oct 5, 2009 at 4:06 PM, Fred Drake fdr...@gmail.com wrote:
On Mon, Oct 5, 2009 at 4:24 PM, Nick Coghlan ncogh...@gmail.com wrote:
When it comes to comments and recommendations for selecting software
packages, developers *are* the end users :)
Yes, most certainly. But developers as
On Mon, Oct 5, 2009 at 4:23 PM, Olemis Lang ole...@gmail.com wrote:
On Mon, Oct 5, 2009 at 4:06 PM, Fred Drake fdr...@gmail.com wrote:
On Mon, Oct 5, 2009 at 4:24 PM, Nick Coghlan ncogh...@gmail.com wrote:
When it comes to comments and recommendations for selecting software
packages,
Nick Coghlan ncoghlan at gmail.com writes:
Oh, I see what you meant now - you were pointing out that lazy
formatting APIs (such as logging) already don't work properly for
alternative formatting mechanisms (such as string.Template).
Logging doesn't work automatically with string.Template as
2009/10/4 INADA Naoki songofaca...@gmail.com:
-1 That requires keeping formatting information around in every string
instance.
Adding new format_string class avoids it.
unicode(foo) = ufoo
format_string(foo) = ffoo
This way's pros:
* Many libraries can use one transition way.
*
* Moderation
[...]
* Flagging as spam
* Captcha ?
In the specific case, neither would have helped.
a) the user making the comment that the package author felt to be
impolite was a real user, with an established, well-known identity,
and long-time member of the community (IIUC). That didn't
2009/10/5 Nick Coghlan ncogh...@gmail.com:
So I would agree that method invocation on literals (particularly string
literals) is an already established language idiom.
And who hasn't ever used 4.56.as_integer_ratio()? :)
--
Regards,
Benjamin
___
Benjamin Peterson wrote:
2009/10/5 Nick Coghlan ncogh...@gmail.com:
So I would agree that method invocation on literals (particularly string
literals) is an already established language idiom.
And who hasn't ever used 4.56.as_integer_ratio()? :)
I've tried 4.__add__ a few times
Barry Warsaw wrote:
I also don't think this is a case of anti-TOOWTDI. For most situations
{}-strings are great (IMO), but in the specific translation domain, I
suspect $-strings are still better.
I agree that keeping string.Template around is valid due to its focus on
being very simple to
Yuvgoog Greenle wrote:
I know this might come through as bike shedding but it's just
customary python that every module have it's own exception types as to
not mix them up with others.
Not in my Python world it isn't. While that is sometimes the right
answer, more often the right answer is to
Antoine Pitrou writes:
Guido van Rossum guido at python.org writes:
There are plenty of things we
can learn about fighting spam and other forms of vandalism from other
areas of the social web, including our very own wiki, and other wikis
(WikiPedia survives despite spam).
At 01:43 PM 10/6/2009 +0900, Stephen J. Turnbull wrote:
IMO it would be better to design developer-specific mechanisms rather
than a generic commenting vehicle, cf. Fred Drake's thinking.
For example, having a packages reddit (nb: open source, written in
Python), where people can upvote or
79 matches
Mail list logo
