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
InnoSetup
2009/10/4 INADA Naoki :
> 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: deprecate
Paul Moore wrote:
Traceback (most recent call last):
File "hello.py", line 13, in
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 sta
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 byte
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 getLogg
On Wed, Oct 7, 2009 at 10:34 AM, Swapnil Talekar 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 fails (say, due
On Wed, Oct 7, 2009 at 9:49 AM, Vinay Sajip 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 therein.
> 2. Use t
Fred Drake 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 or
Olemis Lang 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 have
> 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 f
Vinay Sajip 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 example, do
something lik
On Wed, Oct 7, 2009 at 10:49 AM, Vinay Sajip wrote:
> Olemis Lang 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 fo
On Wed, Oct 7, 2009 at 11:06 AM, Paul Rudin wrote:
> Vinay Sajip 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 d
+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 next
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 pre
Fred Drake wrote:
On Wed, Oct 7, 2009 at 10:34 AM, Swapnil Talekar 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
version, and should, I beli
Paul Rudin 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 co
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 th
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 win
Vinay Sajip 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 opport
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 m
Antoine Pitrou pitrou.net> writes:
>
> Vinay Sajip 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'
On Wed, Oct 7, 2009 at 7:27 PM, M.-A. Lemburg 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 setuptools/Distribute, an
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?
Regards,
Zooko
___
Python-Dev mailing
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
http://mail.python.org/mailm
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 are
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 us
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
Antoine Pitrou wrote:
Vinay Sajip 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
Zooko O'Whielacronx 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.
For
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 dis
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 bui
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 implementa
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 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 Tarek sa
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
Arc Riley 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 mailing list
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 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 active ma
On Wed, 07 Oct 2009 12:35:18 -0700, 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
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
> thei
On Wed, Oct 7, 2009 at 12:42, Ronald Oussoren 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 built and it unconditionally
> imports it under darwin. Turns out that it r
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 t
On Wed, Oct 7, 2009 at 10:43 PM, Sridhar Ratnakumar
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 to stdlib but
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
On Oct 7, 2009, at 3:46 PM, Brett Cannon wrote:
On Wed, Oct 7, 2009 at 12:42, Ronald Oussoren
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 built and it
unconditio
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
provid
Hrvoje Niksic 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 destru
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 l
2009/10/7 Vinay Sajip :
> 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:
...
def extend(self, moreco
On Sun, Sep 20, 2009 at 10:17, Zooko O'Whielacronx wrote:
> On Sun, Sep 20, 2009 at 8:27 AM, Antoine Pitrou wrote:
>> AFAIK, C extensions should fail loading when they have the wrong UCS2/4
>> setting.
>
> That would be an improvement! Unfortunately we instead get mysterious
> misbehavior of th
On Tue, 06 Oct 2009 16:45:29 +0100, Chris Withers
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 have
> the index (
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 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 needed?
>
Glenn Linderman 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 alone.
Of
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 th
>
Thanks to
http://bugs.python.org/issue7077
I've noticed that the socket-based logging handlers - SocketHandler,
DatagramHandler and SysLogHandler - aren't Unicode-aware and can break in the
presence of Unicode messages. I'd like to fix this by giving these handlers an
optional (encoding=None)
62 matches
Mail list logo
