This thread moved to python-ideas so please post only there.
http://mail.python.org/pipermail/python-ideas/2009-October/005924.html
--yuv
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
David Lyon wrote:
Distutils for windows is very, very dead.. grave-ware in-fact.
Now that is not true at all. We have a native Windows installer
(bdist_wininst) and an MSI builder (bdist_msi) that both work
great on Windows.
Plus there are add-ons for other installers such as NSIS and
2009/10/4 INADA Naoki songofaca...@gmail.com:
What about using string prefix 'f'?
f{foo} and {bar} % something == {foo} and {bar}.format(something)
s = f{foo}
t = %(bar)s
s + t # raises Exception
Transition plan:
n: Just add F prefix. And adding format_string in future.
n+1:
Paul Moore wrote:
Traceback (most recent call last):
File hello.py, line 13, in module
main()
File hello.py, line 7, in main
sys.stdout.flush()
IOError: [Errno 9] Bad file descriptor
(Question - is it *ever* possible for a Unix program to have invalid
file descriptors 0,1 and 2? At
I am working on deploying Python on VxWorks platform as a part of project
for my company. Accordingly, I would like to know couple of things from
python's core-developers. Although I think I already know the answers for
most of the questions, we need a confirmation from the community
1) Is the
At present, configuration of Python's logging package can be done in one of two
ways:
1. Create a ConfigParser-readable configuration file and use
logging.config.fileConfig() to read and implement the configuration therein.
2. Use the logging API to programmatically configure logging using
On Wed, Oct 7, 2009 at 10:34 AM, Swapnil Talekar swapnil...@gmail.com wrote:
1) Is the byte-compiled .pyc file and optimized .pyo file
platform-independent?(including python versions 3.x)
Yes.
If yes, is it
guaranteed to stay that way in future?
Yes.
2) If the the generation of .pyc file
On Wed, Oct 7, 2009 at 9:49 AM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
At present, configuration of Python's logging package can be done in one of
two
ways:
1. Create a ConfigParser-readable configuration file and use
logging.config.fileConfig() to read and implement the configuration
Fred Drake fdrake at gmail.com writes:
3) Is it possible to redirect the location of the generation of .pyc files
to other than that of the corresponding .py files?
I think some support for this has been developed, at least
experimentally, but I'm not sure if it's part of a stable release
Olemis Lang olemis at gmail.com writes:
This kind of problems is similar to the one mentioned in another
thread about modifying config options after executing commands. In
that case I mentioned that the same dict-like interface also holds for
WinReg and so on ...
So thinking big (yes ! I
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.
If there is going to be any quick 2.6.4 release, can you consider a fix
Vinay Sajip vinay_sa...@yahoo.co.uk writes:
What's the general feeling here about this proposal? All comments and
suggestions will be gratefully received.
How about the global logging configuration being available as an object
supporting the usual dictionary interface? So you could, for
On Wed, Oct 7, 2009 at 10:49 AM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Olemis Lang olemis at gmail.com writes:
This kind of problems is similar to the one mentioned in another
thread about modifying config options after executing commands. In
that case I mentioned that the same dict-like
On Wed, Oct 7, 2009 at 11:06 AM, Paul Rudin p...@rudin.co.uk wrote:
Vinay Sajip vinay_sa...@yahoo.co.uk writes:
What's the general feeling here about this proposal? All comments and
suggestions will be gratefully received.
How about the global logging configuration being available as an
+1
For a large number of people [1, 2, 3], setuptools is already a
critical part of Python. Make it official. Let everyone know that
future releases of Python will not break setuptools/Distribute, and
that they can rely on backwards-compatibility with the myriad existing
packages. Make the
Folks:
I accidentally sent this letter just to MAL when I intended it to
python-dev. Please read it, as it explains why the issue I'm raising
is not just the we should switch to ucs4 because it is better issue
that was previously settled by GvR. This is a current, practical
problem that is
Fred Drake wrote:
On Wed, Oct 7, 2009 at 10:34 AM, Swapnil Talekar swapnil...@gmail.com wrote:
1) Is the byte-compiled .pyc file and optimized .pyo file
platform-independent?(including python versions 3.x)
Yes.
To be clear, CPython's .pyc is platform independent for a particular x.y
Paul Rudin p...@... writes:
How about the global logging configuration being available as an object
supporting the usual dictionary interface? So you could, for example, do
something like: logging.dictconfig.update(partialconfig)
A partial configuration only makes sense under certain limited
On Wed, Oct 07, 2009 at 10:56:49AM -0600, Zooko O'Whielacronx wrote:
For a large number of people [1, 2, 3], setuptools is already a
critical part of Python. Make it official. Let everyone know that
future releases of Python will not break setuptools/Distribute, and
that they can rely on
Hello everyone.
The source tarballs and Windows installers for Python 2.6.4rc1 are now
available:
http://www.python.org/download/releases/2.6.4/
Please download them, install them, and try to use them with your
projects and environments. Let us know if you encounter any problems
with
P.J. Eby wrote:
At 01:14 PM 10/6/2009 -0700, Guido van Rossum wrote:
suggest nobody hold their breath waiting for setuptools 0.7.
I've never suggested or implied otherwise.
But, if you like Distribute so much, why not just add it directly to the
stdlib? ;-)
There are many wins to be
Vinay Sajip vinay_sajip at yahoo.co.uk writes:
%0#8x % 0x1234
'0x001234'
{0:0#8x}.format(0x1234)
'000x1234'
Apart from the sheer unreadability of the {}-style format string, the result
looks rather unexpected from a human being's point of view.
(in those situations, I would output the
Barry Warsaw wrote:
2.6.4 final is planned for 18-October.
Barry,
I suspect this release is primarily to quench the problems with
distutils, but..
http://bugs.python.org/issue5949
doesn't seem to have been addressed by you. And this seems like it would
be another unfortunate loss of an
Zooko O'Whielacronx wrote:
+1
For a large number of people [1, 2, 3], setuptools is already a
critical part of Python. Make it official. Let everyone know that
future releases of Python will not break setuptools/Distribute, and
that they can rely on backwards-compatibility with the myriad
Antoine Pitrou solipsis at pitrou.net writes:
Vinay Sajip vinay_sajip at yahoo.co.uk writes:
%0#8x % 0x1234
'0x001234'
{0:0#8x}.format(0x1234)
'000x1234'
Apart from the sheer unreadability of the {}-style format string, the result
looks rather unexpected from a human being's
On Wed, Oct 7, 2009 at 7:27 PM, M.-A. Lemburg m...@egenix.com wrote:
Zooko O'Whielacronx wrote:
+1
For a large number of people [1, 2, 3], setuptools is already a
critical part of Python. Make it official. Let everyone know that
future releases of Python will not break
You might be interested in the new PYTHONDONTWRITEBYTECODE environment
variable supported as of Python 2.6. I personally think it is a great
improvement. :-)
Regards,
Zooko
___
Python-Dev mailing list
Python-Dev@python.org
On Oct 7, 2009, at 10:54 AM, Koen van de Sande wrote:
If there is going to be any quick 2.6.4 release, can you consider a
fix to the building of extensions under Windows ( http://bugs.python.org/issue4120
)?
Extensions built without this patch applied will not work if the
MSVC9 runtimes
Zooko O'Whielacronx wrote:
Dear MAL and python-dev:
I failed to explain the problem that users are having. I will try
again, and this time I will omit my ideas about how to improve things
and just focus on describing the problem.
Some users are having trouble using Python packages
On Oct 7, 2009, at 1:26 PM, Scott Dial wrote:
I suspect this release is primarily to quench the problems with
distutils, but..
http://bugs.python.org/issue5949
doesn't seem to have been addressed by you. And this seems like it
would
be another unfortunate loss of an opportunity.
I want
Zooko O'Whielacronx wrote:
Thanks for the reply, MAL.
How would we judge whether Distribute is ready for inclusion in the
Python standard lib? Maybe if it has a few more releases, leaving a
trail of closed: fixed issue tickets behind it?
I guess it'll just have to take the usual path of
Antoine Pitrou wrote:
Vinay Sajip vinay_sajip at yahoo.co.uk writes:
%0#8x % 0x1234
'0x001234'
{0:0#8x}.format(0x1234)
'000x1234'
Apart from the sheer unreadability of the {}-style format string, the result
looks rather unexpected from a human being's point of view.
(in those
Zooko O'Whielacronx zookog at gmail.com writes:
I accidentally sent this letter just to MAL when I intended it to
python-dev. Please read it, as it explains why the issue I'm raising
is not just the we should switch to ucs4 because it is better issue
that was previously settled by GvR.
I'm not really sure how to reply to your email, since it seems to be
based on several major misunderstandings. So, just a few key points:
* Distribute 0.6.x is a stable maintenance branch, much like setuptools 0.6
* Distribute 0.7 is vaporware, very much like setuptools 0.7
* Packages using
On 7 Oct, 2009, at 20:05, M.-A. Lemburg wrote:
If we do go for a change, we should use sizeof(wchar_t)
as basis for the new default - on all platforms that
provide a wchar_t type.
I'd be -1 on that. Sizeof(wchar_t) is 4 on OSX, but all non-Unix API's
that deal with Unicode text use ucs16.
At 07:27 PM 10/7/2009 +0200, M.-A. Lemburg wrote:
Having more competition will also help, e.g. ActiveState's PyPM looks
promising (provided they choose to open-source it) and then there's
pip.
Note that both PyPM and pip use setuptools as an important piece of
their implementation (as does
P.J. Eby wrote:
At 07:27 PM 10/7/2009 +0200, M.-A. Lemburg wrote:
Having more competition will also help, e.g. ActiveState's PyPM looks
promising (provided they choose to open-source it) and then there's
pip.
Note that both PyPM and pip use setuptools as an important piece of
their
On 7 Oct, 2009, at 20:53, Brett Cannon wrote:I just tried building out of svn and a ton of tests that rely on urllib failed because the _scproxy module wasn't built and it unconditionally imports it under darwin. Turns out that it requires the Mac toolbox glue to be built which I always skip since
On Wed, Oct 7, 2009 at 10:37, Zooko O'Whielacronx zoo...@gmail.com wrote:
Thanks for the reply, MAL.
How would we judge whether Distribute is ready for inclusion in the
Python standard lib? Maybe if it has a few more releases, leaving a
trail of closed: fixed issue tickets behind it?
When
Ronald Oussoren wrote:
On 7 Oct, 2009, at 20:05, M.-A. Lemburg wrote:
If we do go for a change, we should use sizeof(wchar_t)
as basis for the new default - on all platforms that
provide a wchar_t type.
I'd be -1 on that. Sizeof(wchar_t) is 4 on OSX, but all non-Unix API's
that deal
Arc Riley arcriley at gmail.com writes:
Is the intention of Pypi really to turn it into a social networking site?
Sure, why not?
It's not like there are enough social networking sites nowadays, are there? :)
Regards
Antoine.
___
Python-Dev
On 7 Oct, 2009, at 22:13, M.-A. Lemburg wrote:
Ronald Oussoren wrote:
On 7 Oct, 2009, at 20:05, M.-A. Lemburg wrote:
If we do go for a change, we should use sizeof(wchar_t)
as basis for the new default - on all platforms that
provide a wchar_t type.
I'd be -1 on that. Sizeof(wchar_t) is
P.J. Eby pje at telecommunity.com writes:
* Distribute 0.6.x is a stable maintenance branch, much like setuptools 0.6
I'm new to this particular discussion so feel free to correct me if I'm wrong,
but ISTM that Distribute 0.6.x differs markedly from setuptools 0.6 in that the
former has an
On Wed, 07 Oct 2009 12:35:18 -0700, P.J. Eby p...@telecommunity.com wrote:
At 07:27 PM 10/7/2009 +0200, M.-A. Lemburg wrote:
Having more competition will also help, e.g. ActiveState's PyPM looks
promising (provided they choose to open-source it) and then there's
pip.
Note that both PyPM and
P.J. Eby wrote:
At 07:27 PM 10/7/2009 +0200, M.-A. Lemburg wrote:
Having more competition will also help, e.g. ActiveState's PyPM looks
promising (provided they choose to open-source it) and then there's
pip.
Note that both PyPM and pip use setuptools as an important piece of
their
On Wed, Oct 7, 2009 at 12:42, Ronald Oussoren ronaldousso...@mac.comwrote:
On 7 Oct, 2009, at 20:53, Brett Cannon wrote:
I just tried building out of svn and a ton of tests that rely on urllib
failed because the _scproxy module wasn't built and it unconditionally
imports it under darwin.
At 08:23 PM 10/7/2009 +, Vinay Sajip wrote:
P.J. Eby writes:
* Distribute 0.6.x is a stable maintenance branch, much like setuptools 0.6
I'm new to this particular discussion so feel free to correct me if I'm wrong,
but ISTM that Distribute 0.6.x differs markedly from setuptools 0.6
in
On Wed, Oct 7, 2009 at 10:43 PM, Sridhar Ratnakumar
sridh...@activestate.com wrote:
PyPM client relies on pkg_resources *only*[1]. Specifically for
1) the version comparison algorithm:
[...]
2) parsing the install_requires string:
[...]
Both these features are definitely worthy of addition
At 10:46 PM 10/7/2009 +0200, M.-A. Lemburg wrote:
P.J. Eby wrote:
At 07:27 PM 10/7/2009 +0200, M.-A. Lemburg wrote:
Having more competition will also help, e.g. ActiveState's PyPM looks
promising (provided they choose to open-source it) and then there's
pip.
Note that both PyPM and pip use
On Oct 7, 2009, at 3:46 PM, Brett Cannon wrote:
On Wed, Oct 7, 2009 at 12:42, Ronald Oussoren
ronaldousso...@mac.com wrote:
On 7 Oct, 2009, at 20:53, Brett Cannon wrote:
I just tried building out of svn and a ton of tests that rely on
urllib failed because the _scproxy module wasn't
Ronald Oussoren wrote:
On 7 Oct, 2009, at 22:13, M.-A. Lemburg wrote:
Ronald Oussoren wrote:
On 7 Oct, 2009, at 20:05, M.-A. Lemburg wrote:
If we do go for a change, we should use sizeof(wchar_t)
as basis for the new default - on all platforms that
provide a wchar_t type.
I'd be -1
Hrvoje Niksic hrvoje.niksic at avl.com writes:
Of course; simply use the - pseudo-redirection, which has been a
standard sh feature (later inherited by ksh and bash, but not csh) for
~30 years. The error message is amusing, too:
$ python -c 'print foo' -
close failed in file object
Ronald Oussoren:
Both Carbon and the modern APIs use UTF-16.
If Unicode size standardization is seen as sufficiently beneficial
then UTF-16 would be more widely applicable than UTF-32. Unix mostly
uses 8-bit APIs which are either explicitly UTF-8 (such as GTK+) or
can accept UTF-8 when the
2009/10/7 Vinay Sajip vinay_sa...@yahoo.co.uk:
What's the general feeling here about this proposal? All comments and
suggestions will be gratefully received.
+1
One option I would have found useful in some code I wrote would be to
extend the configuration -
class DictConfigurator:
...
On Sun, Sep 20, 2009 at 10:17, Zooko O'Whielacronx zoo...@gmail.com wrote:
On Sun, Sep 20, 2009 at 8:27 AM, Antoine Pitrou solip...@pitrou.net wrote:
AFAIK, C extensions should fail loading when they have the wrong UCS2/4
setting.
That would be an improvement! Unfortunately we instead get
On Tue, 06 Oct 2009 16:45:29 +0100, Chris Withers ch...@simplistix.co.uk
wrote:
Well yeah, and the only sane way I can think to handle this is to have a
metadata file that gets uploaded with each distribution that covers all
these things (and the other things that other people need) and then
On approximately 10/7/2009 7:49 AM, came the following characters from
the keyboard of Vinay Sajip:
In outline, the scheme I have in mind will look like this, in terms of the new
public API:
class DictConfigurator:
def __init__(self, config): #config is a dict-like object (duck-typed)
Paul Moore p.f.moore at gmail.com writes:
One option I would have found useful in some code I wrote would be to
extend the configuration -
class DictConfigurator:
...
def extend(self, moreconfig):
import copy
more = copy.deepcopy(moreconfig) # Not sure if this is
Glenn Linderman v+python at g.nevcal.com writes:
But DictConfigurator the name seems misleading... like you are
configuring how dicts work, rather than how logs work. Maybe with more
context this is not a problem, but if it is a standalone class, it is
confusing what it does, by name
I just tried building out of svn and a ton of tests that rely on urllib
failed because the _scproxy module wasn't built and it unconditionally
imports it under darwin. Turns out that it requires the Mac toolbox glue to
be built which I always skip since I don't care about it.
I am fairly certain
60 matches
Mail list logo
