Re: [Python-Dev] comments vs spam in PyPI [was: eggs now mandatory for pypi?]

[Vinay Sajip]

P.J. Eby  telecommunity.com> writes:

> For example, having a packages reddit (nb: open source, written in 
> Python), where people can upvote or downvote packages and leave 
> comments.  That's probably the minimum amount of checks and balances 
> required to avoid problems of the sort the PyPI commenting feature is 
> already having, since others will be able to reply to the comments, 
> and downvote nonsense into oblivion.

Seems like a reasonable idea, given that there's already a Python reddit which
seems popular. There was also www.cheeserater.com (which appears down at the
moment) which was a Django demo site (source available at
http://github.com/jacobian/cheeserater) for rating PyPI packages.

I just created a "cheeseshop" sub-reddit to play around with.

> (Alternatively, shutting off the comment system would also 
> work.  Nothing stops people from using Google to search for "foo 
> sucks" or "problems using foo" if they want to research what's been 
> said about a package.)

Yes, but it's good to have all the feedback in one place, if possible.

Regards,

Vinay Sajip

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] comments vs spam in PyPI [was: eggs now mandatory for pypi?]

[P.J. Eby]

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 downvote packages and leave 
comments.  That's probably the minimum amount of checks and balances 
required to avoid problems of the sort the PyPI commenting feature is 
already having, since others will be able to reply to the comments, 
and downvote nonsense into oblivion.


(Alternatively, shutting off the comment system would also 
work.  Nothing stops people from using Google to search for "foo 
sucks" or "problems using foo" if they want to research what's been 
said about a package.)


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] comments vs spam in PyPI [was: eggs now mandatory for pypi?]

[Stephen J. Turnbull]

Antoine Pitrou writes:
 > Guido van Rossum  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).
 > 
 > Doesn't Wikipedia have a lot of human eyes watching, however?

Yes.  In fact Wikipedia's real issue is not spam, but edit wars.  It
just happens that the same people who are willing to watch to make
sure that nobody "corrects" the facts consider spam damage, too, and
they get rid of it as part of their mission.

What this means is that the most active parts of the Wikipedia are
also quickly policed.  What's left is much less attractive for
spammers, and there are a number of volunteers willing to respond
fairly promptly to reports of spam in articles that nobody currently
considers "theirs".

I think it could probably be adapted to Python community scale, but it
would probably require new mechanisms (spam reporting and possibly
cleaning -- in Wikipedia you hit the revert button, choose a known
good version, and you're done) in PyPI, and recruitment of volunteers
to take care of spam to products currently not "owned".

IMO it would be better to design developer-specific mechanisms rather
than a generic commenting vehicle, cf. Fred Drake's thinking.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 389: argparse - new command line parsing module

[Nick Coghlan]

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 properly scope your try/except
statement in order to avoid catching exceptions from code you aren't
interested in. If you end up stuck with a library call that lacks both
granularity and specificity of exceptions then you live with it (and
maybe file a bug report/feature request with the library author).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] summary of transitioning from % to {} formatting

[Nick Coghlan]

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 use (especially for non-coders producing
translation templates)

However, string.Template is already set up to work for the relevant APIs
in that domain so I don't think it will really be affected by any
changes to the underlying language and library support for brace formatting.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] transitioning from % to {} formatting

[Michael Foord]

Benjamin Peterson wrote:

2009/10/5 Nick Coghlan :
  

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 (not for a while now though).

Michael

--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] transitioning from % to {} formatting

[Benjamin Peterson]

2009/10/5 Nick Coghlan :
> 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
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] eggs now mandatory for pypi?

[Martin v. Löwis]

>> * 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 stop him
from making comments that the package author considered as impolite.

b) the comment itself was not spam, by any convention that I'm familiar
with. It was negative, but it was on-topic (in that it commented on
the very package that it was attached to).

I have said this already in various other places: I feel that the
freedom of speech is of high value, and that PyPI is not only (and
perhaps not primarily) made for the package authors - but for the
package users. If we get spam, we certainly need (and have)
moderation. But in the specific case, I probably would not have
moderated the comment away since it was not spam.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] transitioning from % to {} formatting

[Benjamin Peterson]

2009/10/4 INADA Naoki :
>> -1 That requires keeping formatting information around in every string 
>> instance.
> Adding new "format_string" class avoids it.
>  unicode("foo") <=> u"foo"
>  format_string("foo") <=> f"foo"
>
> This way's pros:
> * Many libraries can use one transition way.
> * Transition stage syncs to Python version. "library A uses {} and
> library B uses %" problem not happen in transition.
> * We have experience same way on unicode.

And all are outweighted by the introduction of a new string class.



-- 
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] summary of transitioning from % to { } formatting

[Vinay Sajip]

Nick Coghlan  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 it pre-dates
string.Template, but it can be made to work without too much trouble:

(a) Subclass Formatter to use $-formatting instead of %-formatting for e.g. the
lines written to log files, and
(b) Use a class like DollarMessage which I mentioned elsewhere in this thread,
to format logging call format strings and arguments.

Both of these approaches will also work for {}-formatting. The present thread
really started out with a view to suggesting that the stdlib start adopting
{}-format as "native", rather than %-format.

Would it be helpful if I added a section to the Python docs about how to use
alternative formatting systems with logging?

Regards,

Vinay Sajip


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] eggs now mandatory for pypi?

[Olemis Lang]

On Mon, Oct 5, 2009 at 4:23 PM, Olemis Lang  wrote:
> On Mon, Oct 5, 2009 at 4:06 PM, Fred Drake  wrote:
>> On Mon, Oct 5, 2009 at 4:24 PM, Nick Coghlan  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 is what I was getting at.
>>
>> The convenience interfaces for commenting on a library are far less
>> valuable for developers, IMO, since developers are expected to better
>> understand how their context impacts their perception.  Useful
>> feedback from a developer just doesn't fit will into the
>> giant-pile-of-comments UIs conventional for non-developers.
>>
>
> +1
>
> IMO :
>
>  - decision matrix are useful to decide which lib to use (i.e. which
>    one supports the features I need ;o). BTW that's something cool about
>    wikipedia ;o)

I mean feature matrix

>  - project metrics and build results are useful to have a idea
>    of project dev status (e.g. coverage, test results, ...).
>  - the rest goes to issue tracker + project (sites | wikis). that's what
>    they are for ;o)
>
> --
> Regards,
>
> Olemis.
>
> Blog ES: http://simelo-es.blogspot.com/
> Blog EN: http://simelo-en.blogspot.com/
>
> Featured article:
> Nabble - Trac Users - Coupling trac and symfony framework  -
> http://feedproxy.google.com/~r/TracGViz-full/~3/hlNmupEonF0/Coupling-trac-and-symfony-framework-td25431579.html
>



-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Nabble - Trac Users - Coupling trac and symfony framework  -
http://feedproxy.google.com/~r/TracGViz-full/~3/hlNmupEonF0/Coupling-trac-and-symfony-framework-td25431579.html
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] eggs now mandatory for pypi?

[Olemis Lang]

On Mon, Oct 5, 2009 at 4:06 PM, Fred Drake  wrote:
> On Mon, Oct 5, 2009 at 4:24 PM, Nick Coghlan  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 is what I was getting at.
>
> The convenience interfaces for commenting on a library are far less
> valuable for developers, IMO, since developers are expected to better
> understand how their context impacts their perception.  Useful
> feedback from a developer just doesn't fit will into the
> giant-pile-of-comments UIs conventional for non-developers.
>

+1

IMO :

  - decision matrix are useful to decide which lib to use (i.e. which
one supports the features I need ;o). BTW that's something cool about
wikipedia ;o)
  - project metrics and build results are useful to have a idea
of project dev status (e.g. coverage, test results, ...).
  - the rest goes to issue tracker + project (sites | wikis). that's what
they are for ;o)

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Nabble - Trac Users - Coupling trac and symfony framework  -
http://feedproxy.google.com/~r/TracGViz-full/~3/hlNmupEonF0/Coupling-trac-and-symfony-framework-td25431579.html
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Package install failures in 2.6.3

[Martin v. Löwis]

>> 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 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.
> 
> The fix makes sure build_ext.get_ext_filename still works as it is supposed
> (just returning the extension of a filename depending on the
> environment) under all versions,

I don't think this is factually correct. I assume you talk about
distribute change e07e5309cd2a, right?

While that change arranges to always return a result when called with an
unqualified module name, it doesn't do the additional computation that
setuptools does in that case, which may give something different in case
the extension is a Library or in case _links_to_dynamic is true.

So I would rather expect that distribute is now broken in these cases
(which are seemingly rare, though).

> It's two lines in Setuptools.

But that change may be incorrect.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] eggs now mandatory for pypi?

[Fred Drake]

On Mon, Oct 5, 2009 at 4:24 PM, Nick Coghlan  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 is what I was getting at.

The convenience interfaces for commenting on a library are far less
valuable for developers, IMO, since developers are expected to better
understand how their context impacts their perception.  Useful
feedback from a developer just doesn't fit will into the
giant-pile-of-comments UIs conventional for non-developers.

If I'm wrong about that, then I'm saddened by the state of the profession.


  -Fred

-- 
Fred L. Drake, Jr.
"Chaos is the score upon which reality is written." --Henry Miller
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] summary of transitioning from % to {} formatting

[Barry Warsaw]

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 necessary - simply
pre-formatting the message seems like it should work, just as
preformatting brace formatted messages already works today).


Yep. :)


The idea of adding an optional "fmt_style" callable to these APIs
(defaulting to None, which would imply the use of the mod operator) is
becoming more appealing...


-Barry



PGP.sig
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Package install failures in 2.6.3

[James Y Knight]

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. I never bothered to  
report it for setuptools as I know it isn't maintained.


It's probably in our best interest to just get people over to  
Distribute, let it continue to hijack setuptools, and slowly let  
that name fade out if it is going to continue to be unmaintained. I  
have to admit I find it really disheartening that we are letting an  
unmaintained project dictate how we fix a bug. I really hope this is  
a one-time deal and from this point forward we all move the  
community towards Distribute so we never feel pressured like this  
again.


Even though the bug was noticed, nobody thought that, just perhaps,  
breaking other software in a minor point release might be a bad idea,  
no matter whether it was updated in less-than-a-week, or mostly- 
unmaintained?


Once you have an API that you encourage people to subclass, *of  
course* it dictates how you can fix a bug.


James
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] transitioning from % to {} formatting

[Nick Coghlan]

Guido van Rossum wrote:
> \>> 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 casualties. In fact, it serves as an early reminder to the
> user that string literals are, in fact, objects like all others.

The other string literal method I personally use reasonably often is to
create lists of strings by using "a list of strings".split() instead of
['a', 'list', 'of', 'strings'] (while the character count isn't all that
different, I find the former is easier to both write and read without
all those quotes and commas). It's a trick I've seen plenty of other
people use as well.

So I would agree that method invocation on literals (particularly string
literals) is an already established language idiom.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] summary of transitioning from % to {} formatting

[Nick Coghlan]

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 string.Template around is valid due to its focus on
>> being very simple to use (especially for non-coders producing
>> translation templates)
>>
>> However, string.Template is already set up to work for the relevant APIs
>> in that domain so I don't think it will really be affected by any
>> changes to the underlying language and library support for brace
>> formatting.
> 
> What if you wanted to translate log messages?  Printing to a StringIO
> first really isn't a very good solution.

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).

(Although printing to a String IO doesn't seem necessary - simply
pre-formatting the message seems like it should work, just as
preformatting brace formatted messages already works today).

The idea of adding an optional "fmt_style" callable to these APIs
(defaulting to None, which would imply the use of the mod operator) is
becoming more appealing...

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] eggs now mandatory for pypi?

[Nick Coghlan]

Fred Drake wrote:
> On Mon, Oct 5, 2009 at 1:54 PM, Guido van Rossum  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 consider it bad to provide support for commenting and
> rating, I find it much less valuable than for end-user-centric sites.
> But then, some may find me a bit retro.  :-/

When it comes to comments and recommendations for selecting software
packages, developers *are* the end users :)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] eggs now mandatory for pypi?

[Nick Coghlan]

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
>> 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 their own PyPI packages, so
> responding to comments requires tracking down the person who left them
> and contacting them in some other way.

Really? I can understand package owners not being able to add
recommendations for their own packages, but if they can't add comments
how are they meant to correct misunderstandings or redirect
inappropriate messages to the correct forums?

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Package install failures in 2.6.3

[P.J. Eby]

At 08:22 PM 10/5/2009 +0100, Michael Foord wrote:
I'm intrigued as to whether setuptools does monkey patch distutils 
or subclass though, they are fundamentally different concepts.


It does both; however, the specific issue under discussion is purely 
a subclassing problem, and one which pywin32 ran afoul of as well.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Package install failures in 2.6.3

[P.J. Eby]

At 11:21 AM 10/5/2009 -0700, Brett Cannon wrote:
I have to admit I find it really disheartening that we are letting 
an unmaintained project dictate how we fix a bug.


Setuptools was not the only project broken by this change.  See:

  http://bugs.python.org/issue7020#msg93355

Apparently, I'm not the only person who read the get_ext_filename() 
docstring that way, and subclassed build_ext in a way that broke 
it.  (In this case, it was pywin32.)


IMO, the fact that it broke Pywin32 in 2.6.3rc1 should have been 
considered evidence that the change was not suitable for a bugfix release.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] summary of transitioning from % to {} formatting

[Barry Warsaw]

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 string.Template around is valid due to its  
focus on

being very simple to use (especially for non-coders producing
translation templates)

However, string.Template is already set up to work for the relevant  
APIs

in that domain so I don't think it will really be affected by any
changes to the underlying language and library support for brace  
formatting.


What if you wanted to translate log messages?  Printing to a StringIO  
first really isn't a very good solution.


-Barry



PGP.sig
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Package install failures in 2.6.3

[Michael Foord]

Brett Cannon wrote:



On Mon, Oct 5, 2009 at 08:44, Barry Warsaw > 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.


The fix makes sure build_ext.get_ext_filename still works as
it is supposed
(just returning the extension of a filename depending on the
environment) under all versions,

*and* continues to do extra work for the Setuptools internal
needs when
it is called by Setuptools itself on various places.

It's two lines in Setuptools.

But beware that a new Setuptools release might take a few
months and
maybe will never happen.
That is why a suggested solution was to install Distribute,
because it
addresses among other
bug fixes, this one.


I think we have two other choices.

2) PJE releases a new version of setuptools that fixes this problem.

3) We (a.k.a. Tarek with our blessing) hijacks the setuptools name
(e.g. on cheeseshop) and releases a new version

I still hope #2 happens, but let's have a deadline for when the
more drastic measures will be taken.


Or we VERY clearly and loudly state in the release notes and anywhere 
else we can that Distribute has replaced setuptools and everyone 
should upgrade immediately because of critical bugs like the one under 
discussion.


+1 - this sounds like a good solution.

I'm intrigued as to whether setuptools does monkey patch distutils or 
subclass though, they are fundamentally different concepts.


Michael



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. I never bothered to report it for 
setuptools as I know it isn't maintained.


It's probably in our best interest to just get people over to 
Distribute, let it continue to hijack setuptools, and slowly let that 
name fade out if it is going to continue to be unmaintained. I have to 
admit I find it really disheartening that we are letting an 
unmaintained project dictate how we fix a bug. I really hope this is a 
one-time deal and from this point forward we all move the community 
towards Distribute so we never feel pressured like this again.


-Brett


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk
  



--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Package install failures in 2.6.3

[Brett Cannon]

On Mon, Oct 5, 2009 at 08:44, Barry Warsaw  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.
>
>  The fix makes sure build_ext.get_ext_filename still works as it is
>> supposed
>> (just returning the extension of a filename depending on the
>> environment) under all versions,
>>
>> *and* continues to do extra work for the Setuptools internal needs when
>> it is called by Setuptools itself on various places.
>>
>> It's two lines in Setuptools.
>>
>> But beware that a new Setuptools release might take a few months and
>> maybe will never happen.
>> That is why a suggested solution was to install Distribute, because it
>> addresses among other
>> bug fixes, this one.
>>
>
> I think we have two other choices.
>
> 2) PJE releases a new version of setuptools that fixes this problem.
>
> 3) We (a.k.a. Tarek with our blessing) hijacks the setuptools name (e.g. on
> cheeseshop) and releases a new version
>
> I still hope #2 happens, but let's have a deadline for when the more
> drastic measures will be taken.


Or we VERY clearly and loudly state in the release notes and anywhere else
we can that Distribute has replaced setuptools and everyone should upgrade
immediately because of critical bugs like the one under discussion.

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. I never bothered to report it for setuptools as I know
it isn't maintained.

It's probably in our best interest to just get people over to Distribute,
let it continue to hijack setuptools, and slowly let that name fade out if
it is going to continue to be unmaintained. I have to admit I find it really
disheartening that we are letting an unmaintained project dictate how we fix
a bug. I really hope this is a one-time deal and from this point forward we
all move the community towards Distribute so we never feel pressured like
this again.

-Brett
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] "PIL" vs. "Imaging" (was Re: eggs now mandatory for pypi?)

[Fredrik Lundh]

On Mon, Oct 5, 2009 at 8:48 PM, P.J. Eby  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 there were such things as "packages" in Python.)

$ more PIL/Image.py
...
# partial release history:
# 1995-09-09 fl   Created
# 1996-03-11 fl   PIL release 0.0
# 1996-04-30 fl   PIL release 0.1b1
...

Looks like the quickest fix is to distribute two source packages, one
built the traditional way to eliminate breakage for people using the
current tarball layout, and one built with "sdist".


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Package install failures in 2.6.3

[P.J. Eby]

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 general policy, then the developers of at least Numpy and Twisted 
should consider themselves warned that bugfix releases may break 
their build processes.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Package install failures in 2.6.3

[P.J. Eby]

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 there that subclasses 
distutils commands in general, or the build_ext command in 
particular.  Numpy, Twisted, the mx extensions...  there are plenty 
of things out there that subclass distutils commands, quite in 
adherence to the rules.  (Note too that subclassing != patching, and 
the ability to subclass and substitute distutils commands is documented.)


It's therefore not appropriate to treat the issue as if it were 
setuptools-specific; it could have broken any other major (or minor) 
package's subclassing of the build_ext command.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] "PIL" vs. "Imaging" (was Re: eggs now mandatory for pypi?)

[P.J. Eby]

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 installed package is called "Imaging".  If you want to 
depend on PIL, you need to add "Imaging" to your dependencies, and 
add a dependency link to http://effbot.org/downloads/ in order to 
make it work...  at least on platforms where you have a compiler.  If 
you're working on Windows, you need to depend on PIL in order to get 
a download to work, but once installed, it's still called 
Imaging.  So, pretty much you're hosed either way.  ;-)


If the package had just *one* name, used consistently for source, 
binaries, and PyPI registration, it would work.  Unfortunately, 
setuptools is not a human being and can't figure out that "PIL" and 
"Imaging" are two different 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 there were such 
things as "packages" in Python.)


When I was first writing setuptools, I tried to get it to work with 
effbot.org packages as best I could, but there were some things I 
just couldn't do without hardcoding special cases, and working around 
this problem was one of them.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] eggs now mandatory for pypi?

[Olemis Lang]

On Mon, Oct 5, 2009 at 1:21 PM, Jesse Noller  wrote:
> On Mon, Oct 5, 2009 at 1:54 PM, Guido van Rossum  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 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).
>>
>
> I agree that feedback, commentary/etc is a Good Thing; but doing it
> right is not an easy thing, and typically implementing it poorly leads
> to spam, people filing bugs in comments, astroturfing, etc. Just on
> first glance, I could see immediate improvements around:
>
> * Moderation
[...]
> * Flagging as spam

* Captcha ?

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Nabble - Trac Users - Coupling trac and symfony framework  -
http://feedproxy.google.com/~r/TracGViz-full/~3/hlNmupEonF0/Coupling-trac-and-symfony-framework-td25431579.html
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] eggs now mandatory for pypi?

[Antoine Pitrou]

Guido van Rossum  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).

Doesn't Wikipedia have a lot of human eyes watching, however?


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] eggs now mandatory for pypi?

[Jesse Noller]

On Mon, Oct 5, 2009 at 1:54 PM, Guido van Rossum  wrote:
> On Mon, Oct 5, 2009 at 10:38 AM, Jesse Noller  wrote:
>> On Mon, Oct 5, 2009 at 12:00 PM, Georg Brandl  wrote:
>>> Jesse Noller schrieb:
 On Mon, Oct 5, 2009 at 4:43 AM, 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)
>
> 

 Unfortunately; we're now staring down the barrel of having
 youtube-style comments on Python packages on the index.
>>>
>>> Yes, unfortunately. I originally thought that restricting the commenters
>>> to those with a PyPI account would make them useful, but seeing this one
>>> (even if it was not intended) and the comment on hgsvn that belongs into
>>> a bug tracker instead, I'm not so sure anymore.
>>>
>>> Georg
>>
>> There would need to be a fair amount of work to make the system useful
>> and almost self-policing. Not to mention people can make plenty of
>> fake pypi accounts for pure astroturfing reasons.
>
> It seems like a worthy cause though. User ratings and comments are the
> future for "app store" style sites such as PyPI, and spam
> unfortunately comes with the terrain. 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).
>

I agree that feedback, commentary/etc is a Good Thing; but doing it
right is not an easy thing, and typically implementing it poorly leads
to spam, people filing bugs in comments, astroturfing, etc. Just on
first glance, I could see immediate improvements around:

* Moderation
* Allowing authors to respond
* Flagging as spam
* Upvoting/downvoting
* Nested conversations

And so on. Sites like stackoverflow/reddit/hackernews/etc have spent a
lot of time "doing it right".

I know, I know - patches welcome. The problem here is that I would
make an argument that in the case of PyPI nothing is better than what
we have currently.

jesse
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] please consider changing --enable-unicode default to ucs4

[Antoine Pitrou]

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 Mandriva X + 1, than about
making it possible to use Fedora RMPs on Mandriva.

In any case, this is quite off-topic for python-dev. If you are
motivated about this, you should try to convinve the Mandriva developers
instead.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] eggs now mandatory for pypi?

[Doug Hellmann]

On Oct 5, 2009, at 4:59 AM, Ben Finney wrote:


Fredrik Lundh  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 it's worth
doing free software, then you're in the wrong social philanthropy
movement.

Make the software good quality, release it in the standard format (in
this case, a Distutils ‘sdist’ on PyPI), respond in a timely manner to
genuine requests for help. Eggs are certainly not a requirement, nor  
is

responding to hostility like the above comment.

If you *want* to respond, you can politely direct them to
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 their own PyPI packages,  
so responding to comments requires tracking down the person who left  
them and contacting them in some other way.


Doug

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] % to .format() converter

[Benjamin Peterson]

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 branch lp:~gutworth/+junk/mod2format".) It
should basically work except for some obscure cases like "%#.0f".

-- 
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] eggs now mandatory for pypi?

[Fred Drake]

On Mon, Oct 5, 2009 at 1:54 PM, Guido van Rossum  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 consider it bad to provide support for commenting and
rating, I find it much less valuable than for end-user-centric sites.
But then, some may find me a bit retro.  :-/


  -Fred

-- 
Fred L. Drake, Jr.
"Chaos is the score upon which reality is written." --Henry Miller
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] eggs now mandatory for pypi?

[Guido van Rossum]

On Mon, Oct 5, 2009 at 10:38 AM, Jesse Noller  wrote:
> On Mon, Oct 5, 2009 at 12:00 PM, Georg Brandl  wrote:
>> Jesse Noller schrieb:
>>> On Mon, Oct 5, 2009 at 4:43 AM, 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)

 
>>>
>>> Unfortunately; we're now staring down the barrel of having
>>> youtube-style comments on Python packages on the index.
>>
>> Yes, unfortunately. I originally thought that restricting the commenters
>> to those with a PyPI account would make them useful, but seeing this one
>> (even if it was not intended) and the comment on hgsvn that belongs into
>> a bug tracker instead, I'm not so sure anymore.
>>
>> Georg
>
> There would need to be a fair amount of work to make the system useful
> and almost self-policing. Not to mention people can make plenty of
> fake pypi accounts for pure astroturfing reasons.

It seems like a worthy cause though. User ratings and comments are the
future for "app store" style sites such as PyPI, and spam
unfortunately comes with the terrain. 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).

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] please consider changing --enable-unicode default to ucs4

[Jan Matejek]

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 compatibility problems like these.
> 
> Trying to use a Fedora or Suse RPM under Mandriva (or the other way 
> round) isn't reasonable and is certainly not supported.
> I don't understand why this so-called "compatibility problem" should be 
> taken seriously by anyone.

You're not making sense. No distro is an island - plus, upstream
distributors have a nasty habit of providing RPMs only for Fedora. I
don't see what is bad about improving compatibility in a place where the
setting doesn't hurt one way or the other.
Besides, the more compatibility we achieve now, the easier time we'll
have once python makes it into LSB

regards
m.

> 
> Regards
> 
> Antoine.
> 
> 
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/jmatejek%40suse.cz
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] eggs now mandatory for pypi?

[Jesse Noller]

On Mon, Oct 5, 2009 at 12:00 PM, Georg Brandl  wrote:
> Jesse Noller schrieb:
>> On Mon, Oct 5, 2009 at 4:43 AM, 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)
>>>
>>> 
>>
>> Unfortunately; we're now staring down the barrel of having
>> youtube-style comments on Python packages on the index.
>
> Yes, unfortunately. I originally thought that restricting the commenters
> to those with a PyPI account would make them useful, but seeing this one
> (even if it was not intended) and the comment on hgsvn that belongs into
> a bug tracker instead, I'm not so sure anymore.
>
> Georg

There would need to be a fair amount of work to make the system useful
and almost self-policing. Not to mention people can make plenty of
fake pypi accounts for pure astroturfing reasons.

jesse
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Package install failures in 2.6.3

[Tarek Ziadé]

On Mon, Oct 5, 2009 at 7:06 PM, M.-A. Lemburg  wrote:
> Tarek Ziadé wrote:
>> On Mon, Oct 5, 2009 at 6:44 PM, Antoine Pitrou  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 (i.e., whether
>>> setuptools is badly written and relies on implementation details) is beyond 
>>> the
>>> point, IMO.
>>
>> Right. As discussed with Barry, I will work on an internal special
>> case in Distutils in the 2.6 maint.
>> branch so it fixes the incompatibility with the Setuptools 0.6c9 release.
>
> You could add a selective work-around that just triggers if setuptools
> has been loaded on the 2.6 branch.
>
> if sys.modules.has_key('setuptools'):
>   # monkey-patch fix-up setuptools to work with the new code
>   ...
>
> or the other way around:
>
> if sys.modules.has_key('setuptools'):
>   # undo r1234 to make setuptools 0.6c9 happy again

Yes I am working on this. I am putting setuptools specific build_ext
command into the distutils
tests to reproduce the issue, then will do a specific setuptools fix,


>   ...
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source  (#1, Oct 05 2009)
 Python/Zope Consulting and Support ...        http://www.egenix.com/
 mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
 mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
> 
>
> ::: Try our new mxODBC.Connect Python Database Interface for free ! 
>
>
>   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
>    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
>           Registered at Amtsgericht Duesseldorf: HRB 46611
>               http://www.egenix.com/company/contact/
>



-- 
Tarek Ziadé | http://ziade.org | オープンソースはすごい! | 开源传万世，因有你参与
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Package install failures in 2.6.3

[M.-A. Lemburg]

Tarek Ziadé wrote:
> On Mon, Oct 5, 2009 at 6:44 PM, Antoine Pitrou  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 (i.e., whether
>> setuptools is badly written and relies on implementation details) is beyond 
>> the
>> point, IMO.
> 
> Right. As discussed with Barry, I will work on an internal special
> case in Distutils in the 2.6 maint.
> branch so it fixes the incompatibility with the Setuptools 0.6c9 release.

You could add a selective work-around that just triggers if setuptools
has been loaded on the 2.6 branch.

if sys.modules.has_key('setuptools'):
   # monkey-patch fix-up setuptools to work with the new code
   ...

or the other way around:

if sys.modules.has_key('setuptools'):
   # undo r1234 to make setuptools 0.6c9 happy again
   ...

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Oct 05 2009)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try our new mxODBC.Connect Python Database Interface for free ! 


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Package install failures in 2.6.3

[Stephen J. Turnbull]

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
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Package install failures in 2.6.3

[Tarek Ziadé]

On Mon, Oct 5, 2009 at 6:44 PM, Antoine Pitrou  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 (i.e., whether
> setuptools is badly written and relies on implementation details) is beyond 
> the
> point, IMO.

Right. As discussed with Barry, I will work on an internal special
case in Distutils in the 2.6 maint.
branch so it fixes the incompatibility with the Setuptools 0.6c9 release.

Tarek.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Package install failures in 2.6.3

[Antoine Pitrou]

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 responsible for the pre-existing mess, and
the lack of maintenance on certain popular software). Knowing who is responsible
doesn't make our users' life any better if nothing's fixed in time.

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 (i.e., whether
setuptools is badly written and relies on implementation details) is beyond the
point, IMO.

[ The issue, of course, is quite different if we come to talk about trunk. ]

> If this choice wins here, it means that setuptools and the stdlib are
> tied together, and that the setuptools package should be integrated to
> the stdlib *immediatly*.

Oh, certainly not. I don't think anybody would want that at this point, even the
most hardcore supporters of setuptools :-)

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Package install failures in 2.6.3

[skip]

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 particular interest.)  Even if everyone did
read blogs, the risk of missing a particular post is extremely high
considering the number of planet.python.org subscriptions.  I don't know how
many blogs are aggregated on planet.python.org but a quick scan suggests
it's well over 100 at this point.

Moral of the story:  If you have something to announce, announce it in the
proper channel: python-announce-l...@python.org.

Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Package install failures in 2.6.3

[Jeroen Ruigrok van der Werven]

-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 support, which have been open for more than a year.

Personally I consider setuptools unmaintained and have started moving my
projects over to Distribute.

So, if you decide to wait, make sure to put a deadline on it.

-- 
Jeroen Ruigrok van der Werven  / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B
The earth laughs in flowers...
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] eggs now mandatory for pypi?

[Georg Brandl]

Jesse Noller schrieb:
> On Mon, Oct 5, 2009 at 4:43 AM, 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)
>>
>> 
> 
> Unfortunately; we're now staring down the barrel of having
> youtube-style comments on Python packages on the index.

Yes, unfortunately. I originally thought that restricting the commenters
to those with a PyPI account would make them useful, but seeing this one
(even if it was not intended) and the comment on hgsvn that belongs into
a bug tracker instead, I'm not so sure anymore.

Georg

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Package install failures in 2.6.3

[Barry Warsaw]

On Oct 5, 2009, at 10:50 AM, Daniel Stutzbach wrote:


On Mon, Oct 5, 2009 at 9:32 AM, Barry Warsaw  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?


He either will or he won't.  Let's give a deadline for when it must  
happen or "we" will do what we need to do.  I think a week to 10 days  
is reasonable.


-Barry



PGP.sig
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Package install failures in 2.6.3

[Barry Warsaw]

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  
supposed

(just returning the extension of a filename depending on the
environment) under all versions,

*and* continues to do extra work for the Setuptools internal needs  
when

it is called by Setuptools itself on various places.

It's two lines in Setuptools.

But beware that a new Setuptools release might take a few months and
maybe will never happen.
That is why a suggested solution was to install Distribute, because it
addresses among other
bug fixes, this one.


I think we have two other choices.

2) PJE releases a new version of setuptools that fixes this problem.

3) We (a.k.a. Tarek with our blessing) hijacks the setuptools name  
(e.g. on cheeseshop) and releases a new version


I still hope #2 happens, but let's have a deadline for when the more  
drastic measures will be taken.


-Barry



PGP.sig
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Package install failures in 2.6.3

[Tarek Ziadé]

On Mon, Oct 5, 2009 at 5:26 PM, M.-A. Lemburg  wrote:
> Tarek Ziadé wrote:
>> On Mon, Oct 5, 2009 at 4:27 PM, 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 together, and that the setuptools package should be integrated to
 the stdlib *immediatly*.
>>>
>>> We've discussed ways of doing that some years ago and found that
>>> it was not possible to make ends join.
>>>
>>> I'd much rather like to see some of the features in setuptools
>>> get implemented in distutils. eGenix could contribute a
>>> bdist_egg implementation that doesn't rely on setuptools and its
>>> monkey patches - along with some other new commands that people
>>> might find useful such as the ability to build Unix libraries,
>>> optional and self-configuring extensions, autoconf-style setups,
>>> etc. (see mxSetup.py in egenix-mx-base for all the details).
>>>
>>> We'd just need some help with integrating the things into
>>> distutils, since we currently don't have the bandwidth for such
>>> things.
>>
>> What about making the Distribute project the laboratory for this work ?
>> It's open to contributions.
>
> The way the distutils extensions are implemented (by sub-classing
> distutils classes) make it easier to add them back to core
> distutils, rather than to integrate them into another 3rd
> party distutils extension.
>
> I'm not sure how adding them to Distribute would help, since then
> you'd only be able to access them using Distribute.

I was thinking about the release cycles but this is maybe because I am
unaware of the way eGenix packages are developed, so I might be wrong.

Distribute has the bandwidth to work on this with many contributors
with a smaller release cycle than stdlib, allowing more feedback.

Notice that I am also doing nightly builds of Distutils that can be installed
and tried in released version of Python, and that can be used instead of the
Python's embed Distutils  (see the installable tarballs at nightly.ziade.org).
so maybe it's just a matter of continuous integration

Tarek

-- 
Tarek Ziadé | http://ziade.org | オープンソースはすごい! | 开源传万世，因有你参与
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] transitioning from % to {} formatting

[Guido van Rossum]

\>> 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 casualties. In fact, it serves as an early reminder to the
user that string literals are, in fact, objects like all others.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Package install failures in 2.6.3

[M.-A. Lemburg]

Tarek Ziadé wrote:
> On Mon, Oct 5, 2009 at 4:27 PM, 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 together, and that the setuptools package should be integrated to
>>> the stdlib *immediatly*.
>>
>> We've discussed ways of doing that some years ago and found that
>> it was not possible to make ends join.
>>
>> I'd much rather like to see some of the features in setuptools
>> get implemented in distutils. eGenix could contribute a
>> bdist_egg implementation that doesn't rely on setuptools and its
>> monkey patches - along with some other new commands that people
>> might find useful such as the ability to build Unix libraries,
>> optional and self-configuring extensions, autoconf-style setups,
>> etc. (see mxSetup.py in egenix-mx-base for all the details).
>>
>> We'd just need some help with integrating the things into
>> distutils, since we currently don't have the bandwidth for such
>> things.
> 
> What about making the Distribute project the laboratory for this work ?
> It's open to contributions.

The way the distutils extensions are implemented (by sub-classing
distutils classes) make it easier to add them back to core
distutils, rather than to integrate them into another 3rd
party distutils extension.

I'm not sure how adding them to Distribute would help, since then
you'd only be able to access them using Distribute.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Oct 05 2009)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try our new mxODBC.Connect Python Database Interface for free ! 


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] eggs now mandatory for pypi?

[M.-A. Lemburg]

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. :)
> As you might already know, "eggs" are not mandatory for pypi. No where
> in the documentation it mentions so. Also many good packages in pypi
> are not eggs (MaL's egenix packages for e.g) and we have known his
> dislike for that particular format too.

I don't dislike the format itself, just the tools that are
available for using it.

We've implemented our own bdist_egg now which doesn't use setuptools
and will start to ship eggs in addition to our prebuilt format with
the next releases.

As time permits, we'll also write an egg installer/uninstaller
(one that does only that ;-).

> But still, sometimes people have found eggs to be convenient.
> 
> That was a particularly harsh comment from jensens, should be ignored
> or he should be corrected that eggs are not mandatory.
> 
> But, i have a feeling that this is going to open up the well known,
> can-of-worms on what is the best distribution format for python
> packages debate.

Let's hope not :-) Besides, the discussions should be about the
tools used for package distribution - the egg format itself
is fine.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Oct 05 2009)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try our new mxODBC.Connect Python Database Interface for free ! 


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Package install failures in 2.6.3

[Tarek Ziadé]

On Mon, Oct 5, 2009 at 4:40 PM,   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 this
> thread.  (I don't read comp.lang.python anymore.  I do read python-dev and
> comp.lang.python.announce.  Maybe I just missed it.)

No you didn't miss it. That's probably my fault because the only places
I publicize about it are my blog (indexed in planet python) and the
distutils-SIG.

Maybe I should blog a summary of the situation and post it to python annoucement
as well.

>
>    Tarek> Now I am astonished that we are talking about reverting changes
>    Tarek> in Distutils that were done for bugfixes, for a third party
>    Tarek> package that does monkey patches on Distutils.
>
> As I said, I was completely unaware of the problems you're addressing with
> Distribute.  My guess is that many extension writers and almost certainly
> those people who install extensions will be similarly unaware of the issues.

Right, and an end-user can't be aware of those. But until they depend on a
project that is not maintained and that we, active people, can't maintain;
we will face such problems.

Now I am dedicated to help all extension writers out there, and as a matter
of fact I've been doing it since a few weeks on #distutils on freenode,
and all the results of this work are contributed in Distribute.

I have written down two important things so far from this thread:

1/ the need to provide a builbdot service for packagers that wish to
try their package against the latest Distutils
2/ the need to publicize what is going on for a wider audience.

Tarek
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Package install failures in 2.6.3

[Tarek Ziadé]

On Mon, Oct 5, 2009 at 4:27 PM, 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 together, and that the setuptools package should be integrated to
>> the stdlib *immediatly*.
>
> We've discussed ways of doing that some years ago and found that
> it was not possible to make ends join.
>
> I'd much rather like to see some of the features in setuptools
> get implemented in distutils. eGenix could contribute a
> bdist_egg implementation that doesn't rely on setuptools and its
> monkey patches - along with some other new commands that people
> might find useful such as the ability to build Unix libraries,
> optional and self-configuring extensions, autoconf-style setups,
> etc. (see mxSetup.py in egenix-mx-base for all the details).
>
> We'd just need some help with integrating the things into
> distutils, since we currently don't have the bandwidth for such
> things.

What about making the Distribute project the laboratory for this work ?
It's open to contributions.

We are also planning to implement early versions of the latest PEP proposals
concerning packaging in this project, once they are finished and accepted,
before it goes into Distutils itself.

>
> Aside: After importing setuptools a lot of things in distutils no
> longer work as advertised. This is due to the heavy monkey patching
> being applied in setuptools.

Yes the code there is very sensitive to any change.

Tarek

-- 
Tarek Ziadé | http://ziade.org | オープンソースはすごい! | 开源传万世，因有你参与
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Package install failures in 2.6.3

[Tarek Ziadé]

On Mon, Oct 5, 2009 at 4:32 PM, Barry Warsaw  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 revert the change in a quick Python 2.6.4.
>>
>> It's technically possible to fix Setuptools. We did this fix on
>> Distribute, and
>> the patch is 2 lines long.
>
> 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 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.

The fix makes sure build_ext.get_ext_filename still works as it is supposed
(just returning the extension of a filename depending on the
environment) under all versions,

*and* continues to do extra work for the Setuptools internal needs when
it is called by Setuptools itself on various places.

It's two lines in Setuptools.

But beware that a new Setuptools release might take a few months and
maybe will never happen.
That is why a suggested solution was to install Distribute, because it
addresses among other
bug fixes, this one.

Tarek

-- 
Tarek Ziadé | http://ziade.org | オープンソースはすごい! | 开源传万世，因有你参与
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Package install failures in 2.6.3

[Daniel Stutzbach]

On Mon, Oct 5, 2009 at 9:32 AM, Barry Warsaw  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?

--
Daniel Stutzbach, Ph.D.
President, Stutzbach Enterprises, LLC 
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Package install failures in 2.6.3

[skip]

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 read python-dev and
comp.lang.python.announce.  Maybe I just missed it.)

Tarek> Now I am astonished that we are talking about reverting changes
Tarek> in Distutils that were done for bugfixes, for a third party
Tarek> package that does monkey patches on Distutils.

As I said, I was completely unaware of the problems you're addressing with
Distribute.  My guess is that many extension writers and almost certainly
those people who install extensions will be similarly unaware of the issues.

Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Package install failures in 2.6.3

[M.-A. Lemburg]

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 together, and that the setuptools package should be integrated to
>> the stdlib *immediatly*.
> 
> We've discussed ways of doing that some years ago and found that
> it was not possible to make ends join.

[just realized that the above could be mistaken for "make ends
 meet" which has a completely different meaning in English than
 the German idiom; what I meant was that no consensus could be
 reached]

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Oct 05 2009)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try our new mxODBC.Connect Python Database Interface for free ! 


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Package install failures in 2.6.3

[Barry Warsaw]

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 possible to fix Setuptools. We did this fix on  
Distribute, and

the patch is 2 lines long.


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 I hope, the answer to that is "yes", then I strongly support  
releasing a fixed setuptools instead of reverting the change to Python.


-Barry



PGP.sig
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Package install failures in 2.6.3

[M.-A. Lemburg]

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 setuptools package should be integrated to
> the stdlib *immediatly*.

We've discussed ways of doing that some years ago and found that
it was not possible to make ends join.

I'd much rather like to see some of the features in setuptools
get implemented in distutils. eGenix could contribute a
bdist_egg implementation that doesn't rely on setuptools and its
monkey patches - along with some other new commands that people
might find useful such as the ability to build Unix libraries,
optional and self-configuring extensions, autoconf-style setups,
etc. (see mxSetup.py in egenix-mx-base for all the details).

We'd just need some help with integrating the things into
distutils, since we currently don't have the bandwidth for such
things.

Aside: After importing setuptools a lot of things in distutils no
longer work as advertised. This is due to the heavy monkey patching
being applied in setuptools. In some cases there's on other way
to adapt distutils to ones needs, but most of the times, a little
more thought put into the OO design of a tool makes it possible to
play nice with distutils without any monkey patching.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Oct 05 2009)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try our new mxODBC.Connect Python Database Interface for free ! 


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Package install failures in 2.6.3

[Tarek Ziadé]

On Mon, Oct 5, 2009 at 3:32 PM, Barry Warsaw  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 would be available and it
>>> would be prudent to at least consider the possibility of a distutils fix.
>>
>> What about a Setuptools release, with the proper fix ?
>
> 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 possible to fix Setuptools. We did this fix on Distribute, and
the patch is 2 lines long.

But it's just a matter of having the maintainer doing it. A few months ago we
couldn't make him fix and release the bug that made setuptools fail
with svn 1.6, and the year before it took several months to get it
fixed for svn 1.5
(a one line, not risky change !!!)

That's why we have forked and created Distribute, to provide bug fixes.

If PJE is not concerned anymore by the maintenance, imho he should let someone
that is willing to do it take over the maintenance of his package to
fix this (and the other problems). That is not a new problem.

Beware that I don't want to run in any new vicious thread here: I had
my share of those.

So about taking over Setuptools maintenance :
1/ I am not saying it should be me, and I am not saying that I am
offended that PJE didn't open the maintenance of setuptools to me.  I
think he should trust the community and let the maintenance of
setuptools be done by all the people that are actively working on the topic.

2/ No, as someone told me in IRC, that's not an evil plan of mine to
make people switch to Distribute. This is not in our interest, it's a
loss-loss situation.

Now I am strongly opposed to revert any bug fix change in Distutils
just because it breaks Setuptools, which is unmaintained since a year.

We have been struggling over a year with this issue. And we are still
struggling because we have to work in a fork to try to provide solutions
for the community, with a lot of bootstrapping issues.

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 setuptools package should be integrated to
the stdlib *immediatly*.

Tarek
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] eggs now mandatory for pypi?

[Olemis Lang]

On Mon, Oct 5, 2009 at 6:26 AM, Jens W. Klein  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, Fredrik Lundh  
>> > wrote:
>> >> it's reviews like this that makes me wonder if releasing open source is
>> >> a good idea:
>> >>

Peace for the world brothers . Lots of yoga, meditation, tai-chi ...
and tons of FOSS

>> >>   no egg - worst seen ever, remove it from pypi or provide an egg
>> >> (jensens, 2009-10-05, 0 points)
>> >>
[...]
>
> Note-to-self: Never post when
> angry about some $whatever.

e.g. I don't do it either when I'm drunk or thinking about Britney  ;o)

> And as far as I understand PIL is not the
> problem, but the packaging/ setuptools.

well I just mentioned few times before (and J. P. Eby said something
too, many times actually ;o) that setuptools solved a crucial problem
that was unsolved when it was released

> For the records: PIL is a great
> piece of software and I dont want to miss it.
>

Yes, and the fact is that without setuptools many other wonderful
(commands | libs | frameworks | apps | software) would be in the
darkness. I mention some of them :

  - setuptools `test` command
  - Trac
  - PasteDeploy
  - ... and here fuel is over ... there are a lot believe me ;o)

the "small" price to pay is that there are a few annoying
implementation details in there ...

> I hope in future we have a packaging-tool solving those problems.
>

... or OTOH that some time is needed to improve it ;o) but considering
the benefits ...

Besides you could use

{{{
$ easy_install -Z eggs_are_awesome.egg
}}}

and the package will be installed directly in the file system ( modify
.pth + PYTHONPATH if desired ;o).

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Nabble - Trac Users - Coupling trac and symfony framework  -
http://feedproxy.google.com/~r/TracGViz-full/~3/hlNmupEonF0/Coupling-trac-and-symfony-framework-td25431579.html
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Package install failures in 2.6.3

[Barry Warsaw]

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 possibility of a  
distutils fix.


What about a Setuptools release, with the proper fix ?


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.


-Barry



PGP.sig
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] eggs now mandatory for pypi?

[Jesse Noller]

On Mon, Oct 5, 2009 at 4:43 AM, 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)
>
> 

Unfortunately; we're now staring down the barrel of having
youtube-style comments on Python packages on the index.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [New-bugs-announce] [issue7064] Python 2.6.3 / setuptools 0.6c9: extension module builds fail with KeyError

[Tarek Ziadé]

On Mon, Oct 5, 2009 at 2:50 PM,   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 packages known to be affected include lxml,
>    Ned> zope-interface, jinja2, and, hence, packages dependent on these
>    Ned> packages (e.g. sphinx, twisted, etc.).
>
> Maybe the Python test suite should include tests with a small number of
> widely used non-core packages like setuptools.  I realize the pybots project
> exists to tackle this sort of stuff in greater detail.  I'm thinking more of
> a smoke test than a comprehensive test suite covering all external packages.
> Setuptools is particularly important because so many extension authors use
> it.  If it breaks it implicitly breaks a lot of PyPI packages.
>

I have created 6 months ago such a buildbot that downloads tarballs
from the community,
and run a few distutils commands on them, and make sure the result is
similar in 2.6/2.7.
and for "sdist" that the resulting tarball is similar.

It was running over Twisted and Numpy, but has been discontinued because
it was on my own server, where it was hard to keep it up (cpu/bandwidth)

If the Snakebite project could host my buildbot (or at least slaves)
or if the PSF could pay for a dedicated
server for this, we would be able to trigger such warnings, and
provide an e-mail service to package maintainers for example.

The build could occur everytime Distutils *or* the project changes.

> Skip
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/ziade.tarek%40gmail.com
>



-- 
Tarek Ziadé | http://ziade.org | オープンソースはすごい! | 开源传万世，因有你参与
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [New-bugs-announce] [issue7064] Python 2.6.3 / setuptools 0.6c9: extension module builds fail with KeyError

[skip]

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> zope-interface, jinja2, and, hence, packages dependent on these
Ned> packages (e.g. sphinx, twisted, etc.).

Maybe the Python test suite should include tests with a small number of
widely used non-core packages like setuptools.  I realize the pybots project
exists to tackle this sort of stuff in greater detail.  I'm thinking more of
a smoke test than a comprehensive test suite covering all external packages.
Setuptools is particularly important because so many extension authors use
it.  If it breaks it implicitly breaks a lot of PyPI packages.

Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Package install failures in 2.6.3

[M.-A. Lemburg]

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.
> 
> What about a Setuptools release, with the proper fix ?

+1

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Oct 05 2009)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try our new mxODBC.Connect Python Database Interface for free ! 


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Package install failures in 2.6.3

[Tarek Ziadé]

On Mon, Oct 5, 2009 at 2:06 PM, Ned Deily  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 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.

It's up to the Setuptools project to provide a release that fixes this problem.
And this fix is one or two lines long.

Distutils will *not* check in its code if it was patched by Setuptools, to
make sure Setuptools 0.6c9 still works.

> 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.

What about a Setuptools release, with the proper fix ?

Tarek
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Package install failures in 2.6.3

[Ned Deily]

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 message.  A number of popular packages are affected 
directly or indirectly through dependencies.

The problem is summarized in the issue tracker here;
   http://bugs.python.org/issue7064
which includes links to the distutils list archive and the setuptools 
and Distribute project bug trackers.

Assuming that distutils is not changed in a forthcoming 2.6.4, users 
and, possibly package maintainers, will need to take some action: either 
migrate from setuptools to Distribute (an easy migration), or wait for a 
fix to setuptools or the package or to the distribution (if there is 
one).

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.

In any case, it seems like there should be some effort to make package 
maintainers aware of the problem so they can take whatever steps 
necessary to update their packages or help files or web sites etc.

-- 
 Ned Deily,
 n...@acm.org

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] eggs now mandatory for pypi?

[Jens W. Klein]

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, Fredrik Lundh  
> > 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 from pypi or provide an egg
> >> (jensens, 2009-10-05, 0 points)
> >>
> >> 
> 
> Actually Jens is a Plone developer ...
> 
> I'm including Jens in this discussion so he may shed some light on his
> comment.
> 
> Christian

I wrote a private message to Frederik (gmail account) and apologised for
my wrong comment. It was targeted wrong. Note-to-self: Never post when
angry about some $whatever. 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. 

I hope in future we have a packaging-tool solving those problems. 

regards Jens

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] eggs now mandatory for pypi?

[Fredrik Lundh]

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* they did that.  That *is* a community problem.

(Luckily, there are people helping out, and the "nice people
driven-development" rule overrides that other rule I mentioned, so
things will get tweaked sooner or later.)



On Mon, Oct 5, 2009 at 1:02 PM, Nick Coghlan  wrote:
> 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 reason egg-based packaging tools make it fairly
> easy to create an egg from a normal sdist package.
>
> As for people being twits... it's the internet. There isn't a lot to be
> done other than to ignore them.
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
> ---
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] eggs now mandatory for pypi?

[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, Fredrik Lundh  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 from pypi or provide an egg
>> (jensens, 2009-10-05, 0 points)
>>
>> 

Actually Jens is a Plone developer ...

I'm including Jens in this discussion so he may shed some light on his
comment.

Christian
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] eggs now mandatory for pypi?

[Nick Coghlan]

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 reason egg-based packaging tools make it fairly
easy to create an egg from a normal sdist package.

As for people being twits... it's the internet. There isn't a lot to be
done other than to ignore them.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] eggs now mandatory for pypi?

[Fred Drake]

On Mon, Oct 5, 2009 at 4:58 AM, Fredrik Lundh  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.
"Chaos is the score upon which reality is written." --Henry Miller
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] transitioning from % to {} formatting

[Nick Coghlan]

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 is
> available, and might not be available for a few more years. Pushing
> the issue probably delays obtaining consensus.

Agreed, but that doesn't rule out discussions of what can be done to
make such a transition easier. And just as 2to3 makes the overall Python
transition practical, a percent to brace format translator should make
an eventual formatting transition feasible.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] eggs now mandatory for pypi?

[Fredrik Lundh]

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, Fredrik Lundh  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 from pypi or provide an egg
> (jensens, 2009-10-05, 0 points)
>
> 
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] eggs now mandatory for pypi?

[Senthil Kumaran]

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 know, "eggs" are not mandatory for pypi. No where
in the documentation it mentions so. Also many good packages in pypi
are not eggs (MaL's egenix packages for e.g) and we have known his
dislike for that particular format too.

But still, sometimes people have found eggs to be convenient.

That was a particularly harsh comment from jensens, should be ignored
or he should be corrected that eggs are not mandatory.

But, i have a feeling that this is going to open up the well known,
can-of-worms on what is the best distribution format for python
packages debate.



-- 
Senthil
No one may kill a man.  Not for any purpose.  It cannot be condoned.
-- Kirk, "Spock's Brain", stardate 5431.6
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] transitioning from % to {} formatting

[Vinay Sajip]

MRAB  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:

>>> "{0:#o}".format(0x1234)
'0o11064'

I couldn't see a backward-compatibility mode for str.format generating just a
leading "0" for octal alternative format (the C style) as opposed to "0o".

Regards,

Vinay Sajip

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] eggs now mandatory for pypi?

[Ben Finney]

Fredrik Lundh  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 it's worth
doing free software, then you're in the wrong social philanthropy
movement.

Make the software good quality, release it in the standard format (in
this case, a Distutils ‘sdist’ on PyPI), respond in a timely manner to
genuine requests for help. Eggs are certainly not a requirement, nor is
responding to hostility like the above comment.

If you *want* to respond, you can politely direct them to
http://docs.python.org/install/> where they can learn how to
install Python distributions — no mention of eggs at all.

-- 
 \ “What is it that makes a complete stranger dive into an icy |
  `\   river to save a solid gold baby? Maybe we'll never know.” —Jack |
_o__)   Handey |
Ben Finney

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] transitioning from % to {} formatting

[MRAB]

Vinay Sajip wrote:

Raymond Hettinger  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'

"{0:0>#8x}".format(0x1234)

'000x1234'

Someone please tell me if there's a better {}-format string which I've missed!


>>> "{0:#08x}".format(0x1234)
'0x001234'
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] transitioning from % to {} formatting

[Paul Moore]

2009/10/5 Vinay Sajip :
> Raymond Hettinger  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'
 "{0:0>#8x}".format(0x1234)
> '000x1234'

>
> Someone please tell me if there's a better {}-format string which I've missed!

Ironically,

>>> "0x{0:0>6x}".format(0x1234)
'0x001234'

ignoring the # modifier altogether...

Paul.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] eggs now mandatory for pypi?

[Fredrik Lundh]

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)


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] transitioning from % to {} formatting

[Vinay Sajip]

Raymond Hettinger  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'
>>> "{0:0>#8x}".format(0x1234)
'000x1234'
>>>

Someone please tell me if there's a better {}-format string which I've missed!

Regards,

Vinay Sajip

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] transitioning from % to {} formatting

[Nick Coghlan]

Vinay Sajip wrote:
> Nick Coghlan  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. A reverse
>> converter may have to punt with ValueError when it finds things that
>> cannot be expressed in the fmt_percent mini language though.
> 
> I've done a first cut of a forward (% -> {}) converter:
> 
> http://gist.github.com/200936
> 
> but I'm not sure there's a case for a converter in the reverse direction, if
> we're encouraging movement in one particular direction.

It would allow an application to still use brace formatting throughout
even if one particularly library only accepted percent formatting.
Probably not worth the effort at this point though, as if we can get a
reliable forward converter happening then it may become possible for
APIs to correctly guess which kind of format string they have been passed.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com