Adam Olsen wrote:
> 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 myste
Tarek Ziadé wrote:
> On Thu, Oct 8, 2009 at 9:35 AM, M.-A. Lemburg wrote:
>> BTW: Who would I need to contact for the PyPI side to work out
>> an upload_url distutils command ?
>
> I am not sure to understand. How upload_url will differ from the
> register command
> t
I have just a few comments to make, so I'm trimming the long quote
a bit...
> Tarek Ziadé a écrit :
>> == Version comparison ==
>>
>> One very important point: we will not force the community to use the
>> scheme described in PEP 386, but *there is* already a
>> de-facto convention on version sche
Tarek Ziadé wrote:
> On Thu, Oct 8, 2009 at 10:38 AM, M.-A. Lemburg wrote:
>> Tarek Ziadé wrote:
>>> On Thu, Oct 8, 2009 at 9:35 AM, M.-A. Lemburg wrote:
>>>> BTW: Who would I need to contact for the PyPI side to work out
>>>> an upload_url distutils com
Tarek Ziadé wrote:
> On Thu, Oct 8, 2009 at 1:27 PM, M.-A. Lemburg wrote:
>>
>>>> == The fate of setup.py, and static metadata ==
>>>>
>>>> So we are going to separate the metadata description from setup.py, in
>>>> a static configurati
Tarek Ziadé wrote:
> On Thu, Oct 8, 2009 at 4:55 PM, M.-A. Lemburg wrote:
>> OTOH, the register command sends the meta-data directly to
>> the PyPI database, so it doesn't even need another file
>> for storing away the meta data.
>>
>> Unless I'm missi
David Lyon wrote:
> On Thu, 08 Oct 2009 09:35:57 +0200, "M.-A. Lemburg" wrote:
>>> One could say that much of the setuptools cloud came about because of
>>> the lack of the queryable download url. Setuptools does a lot of work
>>> here to 'work-around
Tarek Ziadé wrote:
> On Fri, Oct 9, 2009 at 10:20 AM, M.-A. Lemburg wrote:
>>
>> I know that the issue tracker for PyPI is (still) on SF, but
>> development appear to happen elsewhere and I can't find any
>> contact information on the PyPI web pages.
>
>
Christian Heimes wrote:
> Nick Coghlan wrote:
>> Importing yet-another-module for use in site.py doesn't sound like a
>> great idea, so it may make sense to migrate that information into the
>> sys module is this approach is taken. "sys.name" is a little generic
>> though - something more explicit
"Martin v. Löwis" wrote:
>> I know that the issue tracker for PyPI is (still) on SF, but
>> development appear to happen elsewhere and I can't find any
>> contact information on the PyPI web pages.
>
> PyPI discussion takes place mostly on catalog-sig.
Ok, then I'll sign up there.
Thanks,
--
Ma
Benjamin Peterson wrote:
> I forgot to ask before: Does this deprecate platform.python_implementation()?
No, platform.py is meant to be portable across multiple Python
versions and as such not really suitable for such deprecations.
It'll also take a long while before all Python implementations
ex
Nick Coghlan wrote:
> M.-A. Lemburg wrote:
>> Benjamin Peterson wrote:
>>> I forgot to ask before: Does this deprecate
>>> platform.python_implementation()?
>>
>> No, platform.py is meant to be portable across multiple Python
>> versions and as s
"Martin v. Löwis" wrote:
>> id (required):
>> lower case identifier, for example "cpython", "ironpython", "jython",
>> "pypy"
>
> Doing some bike-shedding: I'd like to not use "cpython" as the name of
> the python.org implementation. This term, I believe, was coined around
> JPython, somehow mak
Christian Heimes wrote:
> sys.implementation
> --
>
> platform (required):
> platform or language of the implementation, for example "C", ".NET",
> "Java"
I'd call this attribute "language". We already have sys.platform with
a different meaning.
Possible values would then be "C
Nick Coghlan wrote:
> M.-A. Lemburg wrote:
>>> sys.userdirsuffix
>>> -
>>>
>>> sys.userdirsuffix is an implementation and platform specific string that
>>> is used to construct the path for the user site directory as explained
>&g
Barry Warsaw wrote:
> Are we on track to release 2.6.4 final this Sunday or do we need another
> rc?
>
> Yesterday, Tarek committed another setuptools related fix and said that
> he was going to run a bunch of build tests locally. Tarek, how did that
> go?
>
> Please note that issue 7064 is stil
"Martin v. Löwis" wrote:
>
>> It would be nice to get this issue resolved out for 2.6.4:
>>
>> http://bugs.python.org/issue4120
>>
>> The problem is that extensions built with 2.6.x will not work
>> when used with a User-only installation of Python on machines that
>> don't already have the MS VC9
P.J. Eby wrote:
> At 08:27 AM 10/13/2009 -0400, Barry Warsaw wrote:
>> Are we on track to release 2.6.4 final this Sunday or do we need
>> another rc?
>>
>> Yesterday, Tarek committed another setuptools related fix and said
>> that he was going to run a bunch of build tests locally. Tarek, how
>>
"Martin v. Löwis" wrote:
>
>>> As this bug already exists in 2.6.2, I don't think the change is
>>> eligible for 2.6.4.
>>>
>>> In addition, I want to review it, which I won't be able to until
>>> Sunday.
>>
>> Then I'd suggest to wait another week with 2.6.4 to give you a
>> chance to look at the
Barry Warsaw wrote:
> On Oct 13, 2009, at 11:01 AM, M.-A. Lemburg wrote:
>
>> Then I'd suggest to wait another week with 2.6.4 to give you a
>> chance to look at the patch.
>
> That's not a good option, IMO. We have a known broken 2.6.3 out there
> and
Barry Warsaw wrote:
> On Oct 13, 2009, at 1:07 PM, M.-A. Lemburg wrote:
>
>> Would it be reasonable to shorten that period, if the fix for the
>> mentioned problem gets ready for prime time earlier ?
>
> I think there are many 2.6.x bugs queued up for after 2.6.4 is
>
Curt Hagenlocher wrote:
> On Wed, Oct 21, 2009 at 1:51 PM, Antoine Pitrou wrote:
>>
>> Kristján Valur Jónsson ccpgames.com> writes:
>>>
>>> You are right, on windows time.clock() is based relative to its first call
>>> in the process. There is no such promise made on unix.
>>> QueryPerformanceCo
Tarek Ziadé wrote:
> Hello,
>
> Since the addition of PEP 370, (per-user site packages), site.py and
> distutils/command/install.py are *both* providing the various
> installation directories for Python,
> depending on the system and the Python version.
>
> We have also started to discuss lately
Antoine Pitrou wrote:
> Guido van Rossum python.org> writes:
>>
>> Is it even wort doing a 2.7 release? Isn't the effort better spent on
>> 3.2 alone? (Note, these aren't rhetorical questions. It's well
>> possible that there are good reasons for pushing along with 2.7. Maybe
>> considering those
Raymond Hettinger wrote:
> In all these matters, I think the users should get a vote. And that
> vote should be cast with their decision to stay with 2.x, or switch to
> 3.x, or try to support both. We should not muck with their rational
> decision making by putting "carrots" in one pile and aban
Guido van Rossum wrote:
> I've checked draft (!) PEP 3003, "Python Language Moratorium", into
> SVN. As authors I've listed Jesse, Brett and myself.
>
> On python-ideas the moratorium idea got fairly positive responses
> (more positive than I'd expected, in fact) but I'm bracing myself for
> fierc
"Martin v. Löwis" wrote:
>>> 2.7 has an up-to-date backport of the C IO lib (as well as the memoryview
>>> object), which means it is better for people wanting to ease transition to
>>> 3.x.
>>>
>>> But of course, as Martin said, few people will want to support 2.7 only and
>>> not
>>> 2.6.
>>
>
Nick Coghlan wrote:
> Lennart Regebro wrote:
>> I also would really like to see a real port of the bytes class to 2.6,
>> but I have a vague memory that there was some reason that wouldn't
>> work.
>
> Not so much that it wouldn't work, but that the interfaces to support
> using it effectively rea
Tarek Ziadé wrote:
> On Mon, Nov 16, 2009 at 8:15 PM, Toshio Kuratomi wrote:
> [..]
>> I've brought the issue of Makefile and pyconfig.h being needed for distutils
>> to the attention of every new Fedora python maintainer since the package
>> split was made. The current maintainer, David Malcolm,
The wiki page for porting to 3.x says:
http://wiki.python.org/moin/PortingExtensionModulesToPy3k
"""
long/int Unification
In Python 3.0, there is only one integer type. It is called int on the Python
level, but actually
corresponds to 2.x's long type. In the C-API, PyInt_* functions are replaced
Eric Smith wrote:
> M.-A. Lemburg wrote:
>> Since package developers are just starting to port things to 3.x and
>> many appear to be considering supporting both 2.7 and 3.1 (including
>> myself), I find it a bit strange that such an import aliasing header
>> was remove
"Martin v. Löwis" wrote:
>> IMHO, that's not really a good way to encourage people to try to provide
>> a smooth upgrade to the 3.x branch. Much to the contrary. 3.x should make
>> it easier for developers by providing more standard helpers like
>> the removed intobject.h header file.
>
> I think
Mark Dickinson wrote:
> On Mon, Nov 23, 2009 at 10:44 AM, M.-A. Lemburg wrote:
>> Thanks for pointing me to the that ticket.
>>
>> Looks like Guido already commented on this, so intobject.h could
>> be revived in some form.
>
> I'm wondering how a resurrec
Tarek Ziadé wrote:
> == code, status, next steps ==
>
> The code of the module can be viewed here, it's a revamp of
> distutils.sysconfig:
>
> http://svn.python.org/view/*checkout*/python/branches/tarek_sysconfig/Lib/sysconfig.py?content-type=text%2Fplain
>
> I've refactored distutils/ and site
Karen Tracey wrote:
> In testing some existing code with the 2.7 alpha release, I've run into:
>
> TypeError: Unicode-objects must be encoded before hashing
>
> when the existing code tries to pass unicode objects to hashlib.sha1 and
> hashlib.md5. This is, I believe, due to changes made for
Michael Foord wrote:
> On 15/12/2009 11:23, M.-A. Lemburg wrote:
>> Karen Tracey wrote:
>>
>>> In testing some existing code with the 2.7 alpha release, I've run into:
>>>
>>> TypeError: Unicode-objects must be encoded before hashing
>&
Tarek Ziadé wrote:
> On Mon, Dec 14, 2009 at 10:52 AM, M.-A. Lemburg wrote:
> [..]
>>> I've refactored distutils/ and site.py so they work with this new
>>> module, and added deprecation warnings in distutils.sysconfig.
>>
>> I think we really
Guido van Rossum wrote:
> On Fri, Jan 8, 2010 at 6:34 AM, Antoine Pitrou wrote:
>> Victor Stinner haypocalc.com> writes:
>>>
>>> I wrote a new version of my patch (version 3):
>>>
>>> * don't change the default behaviour: use open(filename, encoding="BOM") to
>>> check the BOM is there is any
>>
Tres Seaver wrote:
> M.-A. Lemburg wrote:
>
>> Shouldn't this encoding guessing be a separate function that you call
>> on either a file or a seekable stream ?
>
>> After all, detecting encodings is just as useful to have for non-file
>> streams.
>
>
Victor Stinner wrote:
> (2) Check for a BOM while reading or detect it before?
>
> Everybody agree that checking BOM is an interesting option and should not be
> limited to open().
>
> Marc-Andre proposed a codecs.guess_file_encoding() function accepting a file
> name or a binary file-like obje
Olemis Lang wrote:
>> On Thu, Jan 7, 2010 at 4:10 PM, Victor Stinner
>> wrote:
>>> Hi,
>>>
>>> Builtin open() function is unable to open an UTF-16/32 file starting with a
>>> BOM if the encoding is not specified (raise an unicode error). For an UTF-8
>>> file starting with a BOM, read()/readline()
Brett Cannon wrote:
> Michael has given me the hg transition/stdlib time slot at the language
> summit this year. In regards to that I plan to lead a discussion on:
>
> * where we are at w/ the Hg transition (Dirkjan should be there and I did a
> blog post on this topic recently:
> http://sayspy.b
Nick Coghlan wrote:
> Guido van Rossum wrote:
>> On Wed, Jan 13, 2010 at 9:57 AM, sstein...@gmail.com > Or, how about
>> just removing the antiquated use of environment variables altogether
>> from Python 3 and avoid the issue completely.
>>
>> -1. They have their use, but more in controlled situat
Ralf Schmitt wrote:
> "M.-A. Lemburg" writes:
>
>>
>> Naive users won't have PYTHONPATH or any other Python environment
>> variables setup.
>>
>> Really, if you know that you are going to run Python 3 instead of
>> Python 2 or vice-ve
David Malcolm wrote:
> I'm thinking of making this downstream change to Fedora's site.py (and
> possibly in future RHEL releases) so that the default encoding
> automatically picks up the encoding from the locale:
>
> def setencoding():
> """Set the string encoding used by the Unicode implem
David Malcolm wrote:
> On Wed, 2010-01-20 at 22:37 +0100, M.-A. Lemburg wrote:
> Note that pango isn't even doing the module reload hack; it's written in
> C, and going in directly through the C API:
>PyUnicode_SetDefaultEncoding("utf-8");
>
> I should
Michael Foord wrote:
> On 20/01/2010 21:37, M.-A. Lemburg wrote:
>> The only supported default encodings in Python are:
>>
>> Python 2.x: ASCII
>> Python 3.x: UTF-8
>>
>
> Is this true? I thought the default encoding in Python 3 was platform
> spe
Michael Foord wrote:
> On 21/01/2010 11:15, M.-A. Lemburg wrote:
>> Michael Foord wrote:
>>
>>> On 20/01/2010 21:37, M.-A. Lemburg wrote:
>>>
>>>> The only supported default encodings in Python are:
>>>>
>>>>Python 2.
Michael Foord wrote:
As always: It's better not to rely on such defaults and explicitly
provide the encoding as parameter where possible.
>>> Sure. I do worry that developers will still rely on the default behavior
>>> assuming that Python 3 "fixes their encoding pr
Karen Tracey wrote:
> On Fri, Jan 22, 2010 at 7:38 AM, Michael Foord
> wrote:
>
>> On 21/01/2010 21:21, "Martin v. Löwis" wrote:
>>
>>> Where the default *file system encoding* is used (i.e. text files are
written or read without specifying an encoding)
>>> I think you misunderstan
"Martin v. Löwis" wrote:
>> This all begs the question: why is there a default? and why is the
>> default a guess?
>>
>> I have to admit that I was completely oblivious to this potential
>> pitfall, and mostly that's because in the most common case, I am working
>> with ASCII files.
>
> You answer
"Martin v. Löwis" wrote:
>> No, but it's most likely a wrong guess, since text files don't
>> really have anything to do with what the user wants to see in
>> a user interface.
>
> That also depends on the operating system. On Windows, there is
> a long tradition of encoding all text in the system
Antoine Pitrou wrote:
> M.-A. Lemburg egenix.com> writes:
>>
>> It's rather common to exchange text files between users... and
>> in form of XML and CSV files, these also tend to get used as
>> input for programs every now and then
>
> For XML files, en
Nick Coghlan wrote:
> M.-A. Lemburg wrote:
>> "Martin v. Löwis" wrote:
>>> Hmm - what do you mean by "normally"? Normally, text files are meant
>>> for human readers, not for exchange between programs.
>>
>> It's rather common to ex
Antoine Pitrou wrote:
> Le samedi 23 janvier 2010 à 20:43 +0100, M.-A. Lemburg a écrit :
>>
>> Now, we cannot easily remove this guessing since we're in stable
>> mode again with 3.1. Perhaps we should add a way to at least be
>> able to switch off this guess
Nick Coghlan wrote:
> Tres Seaver wrote:
>>> Perhaps we could also add a warning to the open() API which warns
>>> in case a file is opened in text mode without specifying an
>>> encoding ?!
>>
>> That sounds like a good plan to me, given that backward-compatibility
>> requires keeping the guessing
Benjamin Peterson wrote:
> 2010/1/25 Steve Howell :
>> I am interested in creating a patch to make deleting elements from the front
>> of Python list work in O(1) time by advancing the ob_item pointer.
>
> How about just using a deque?
... or a stack:
http://www.egenix.com/products/pytho
Collin Winter wrote:
> I added startup benchmarks for Mercurial and Bazaar yesterday
> (http://code.google.com/p/unladen-swallow/source/detail?r=1019) so we
> can use them as more macro-ish benchmarks, rather than merely starting
> the CPython binary over and over again. If you have ideas for bette
Raymond Hettinger wrote:
>
> On Jan 30, 2010, at 4:00 PM, Barry Warsaw wrote:
>> Abstract
>>
>>
>> This PEP describes an extension to Python's import mechanism which
>> improves sharing of Python source code files among multiple installed
>> different versions of the Python interpreter.
>
M.-A. Lemburg wrote:
> Collin Winter wrote:
>> I added startup benchmarks for Mercurial and Bazaar yesterday
>> (http://code.google.com/p/unladen-swallow/source/detail?r=1019) so we
>> can use them as more macro-ish benchmarks, rather than merely starting
>> the CPython
Collin Winter wrote:
> Hey MA,
>
> On Mon, Feb 1, 2010 at 9:58 AM, M.-A. Lemburg wrote:
>> BTW: Some years ago we discussed the idea of pluggable VMs for
>> Python. Wouldn't U-S be a good motivation to revisit this idea ?
>>
>> We could then have a VM based
Collin Winter wrote:
> On Mon, Feb 1, 2010 at 11:17 AM, M.-A. Lemburg wrote:
>> Collin Winter wrote:
>>> I think this idea underestimates a) how deeply the current CPython VM
>>> is intertwined with the rest of the implementation, and b) the nature
>>> of th
Nick Coghlan wrote:
> M.-A. Lemburg wrote:
>> BTW: I also doubt that Mercurial will make any of this easier.
>> It makes creating branches easier for non-committers, but the
>> problem of having to maintain the branches remains.
>
> It greatly simplifies the process of
> On 03/02/2010 06:50, Barry Warsaw wrote:
>> As to the question of sibling directories or folder-per-folder I think
>> performance issues should be the deciding factor. There are file system
>> limitations to consider (but also a wide variety of file systems in
>> use). Do
>> the number of stat
Reid Kleckner wrote:
> On Tue, Feb 2, 2010 at 8:57 PM, Collin Winter wrote:
>>> Wouldn't it be possible to have the compiler approach work
>>> in three phases in order to reduce the memory footprint and
>>> startup time hit, ie.
>>>
>>> 1. run an instrumented Python interpreter to collect all
>>>
Nick Coghlan wrote:
> Barry Warsaw wrote:
>> On Jan 31, 2010, at 01:44 PM, Nick Coghlan wrote:
>>
>>> We deliberate don't document -U because its typical effect is "break the
>>> world" - it makes all strings unicode in 2.x.
It only affects string literals, not all strings.
>> As an aside, I thin
exar...@twistedmatrix.com wrote:
> On 02:52 pm, m...@egenix.com wrote:
>>
>> Note that in Python 2.7 you can use
>>
>> from __future__ import unicode_literals
>>
>> on a per module basis to achieve much the same effect.
>
> In Python 2.6 as well.
Right, but there are a few issues in 2.6 t
exar...@twistedmatrix.com wrote:
> On 03:21 pm, m...@egenix.com wrote:
>> exar...@twistedmatrix.com wrote:
>>> On 02:52 pm, m...@egenix.com wrote:
Note that in Python 2.7 you can use
from __future__ import unicode_literals
on a per module basis to achieve much
Barry Warsaw wrote:
> On Feb 03, 2010, at 11:59 AM, M.-A. Lemburg wrote:
>
>> How about using an optionally relative cache dir setting to let
>> the user decide ?
>
> Why do we need that level of flexibility?
It's very easy to implement (see the code I posted) a
larry.hastings wrote:
> Author: larry.hastings
> Date: Thu Mar 25 01:54:54 2010
> New Revision: 79397
>
> Log:
> Backported PyCapsule from 3.1, and converted most uses of
> CObject to PyCapsule.
Backporting PyCapsule is fine, but the changes you made to all
those PyCObject uses does not look back
larry.hastings wrote:
> Author: larry.hastings
> Date: Thu Mar 25 01:54:54 2010
> New Revision: 79397
>
> Log:
> Backported PyCapsule from 3.1, and converted most uses of
> CObject to PyCapsule.
Backporting PyCapsule is fine, but the changes you made to all
those PyCObject uses does not look back
Larry Hastings wrote:
>
> M.-A. Lemburg wrote:
>> Backporting PyCapsule is fine, but the changes you made to all
>> those PyCObject uses does not look backwards compatible.
>>
>> The C APIs exposed by the modules (e.g. the datetime module)
>> are used in lot
Larry Hastings wrote:
>
> M.-A. Lemburg wrote:
>> Backporting PyCapsule is fine, but the changes you made to all
>> those PyCObject uses does not look backwards compatible.
>>
>> The C APIs exposed by the modules (e.g. the datetime module)
>> are used in lot
Victor Stinner wrote:
> Python 3.0 introduced PyUnicode_DecodeFSDefault() and
> PyUnicode_DecodeFSDefaultAndSize() functions. These functions fallback to
> UTF-8 if getting the file system encoding failed or the encoding is unknown
> (there is not nl_langinfo(CODESET) function).
>
> UTF-8 is no
Victor Stinner wrote:
> There are two opposite issues in the bug tracker:
>
>#7475: codecs missing: base64 bz2 hex zlib ...
>-> reintroduce the codecs removed from Python3
>
>#8838: Remove codecs.readbuffer_encode()
>-> remove the last part of the removed codecs
>
> If I understo
Nick Coghlan wrote:
> On 09/06/10 18:41, M.-A. Lemburg wrote:
>> The methods to be used will be .transform() for the encode direction
>> and .untransform() for the decode direction.
>
> +1, although adding this for 3.2 would need an exception to the
> moratorium approved
Antoine Pitrou wrote:
> On Wed, 09 Jun 2010 10:41:29 +0200
> "M.-A. Lemburg" wrote:
>>
>> The above example will read:
>>
>> >>> b'abc'.transform("hex")
>> b'616263'
>> >>> b'6162
Victor Stinner wrote:
> Le mercredi 09 juin 2010 10:41:29, M.-A. Lemburg a écrit :
>> No, .transform() and .untransform() will be interface to same-type
>> codecs, i.e. ones that convert bytes to bytes or str to str. As with
>> .encode()/.decode() these helper methods also
Michael Foord wrote:
>> How does throwing away information represent "moving forward"?
>
> I'm inclined to agree. There is no *need* to close these tickets now.
>
>> I have to say I am surprised by the current lack of momentum behind 3.x,
>> but I do know users who consider that their current inv
Walter Dörwald wrote:
> On 09.06.10 14:47, Nick Coghlan wrote:
>
>> On 09/06/10 22:18, Victor Stinner wrote:
>>> Le mercredi 09 juin 2010 10:41:29, M.-A. Lemburg a écrit :
>>>> No, .transform() and .untransform() will be interface to same-type
>>>> cod
Barry Warsaw wrote:
> On Jun 21, 2010, at 12:34 PM, Toshio Kuratomi wrote:
>
>> I like the idea of having encoding information carried with the data.
>> I don't think that an ebytes type that can *optionally* have an encoding
>> attribute makes the situation less confusing, though.
>
> Agreed. I
Guido van Rossum wrote:
> [Just addressing one little issue here; generally I'm just happy that
> we're discussing this issue in such detail from so many points of
> view.]
>
> On Mon, Jun 21, 2010 at 10:50 PM, Toshio Kuratomi wrote:
>> [...] Would urljoin(b_base, b_subdir) => bytes and
>> urljoi
Nick Coghlan wrote:
> On Wed, Jun 23, 2010 at 4:09 AM, M.-A. Lemburg wrote:
>> It would be great if we could have something like the above as
>> builtin method:
>>
>> x.split('&'.as(x))
>
> As per my other message, another possible (and reasonably
Lennart Regebro wrote:
> On Tue, Jun 22, 2010 at 20:07, James Y Knight wrote:
>> Yeah. This is a real issue I have with the direction Python3 went: it pushes
>> you into decoding everything to unicode early, even when you don't care --
>
> Well, yes, maybe even if *you* don't care. But often the
Scott Dial wrote:
> On 6/24/2010 5:09 PM, Barry Warsaw wrote:
>>> What use case does this address?
>>
>>> If you want to make it so a system can install a package in just one
>>> location to be used by multiple Python installations, then the version
>>> number isn't enough. You also need to distin
Brett Cannon wrote:
> On Wed, Jun 23, 2010 at 14:53, Brett Cannon wrote:
>> I finally realized why clang has not been silencing its warnings about
>> unused return values: I have -Wno-unused-value set in CFLAGS which
>> comes before OPT (which defines -Wall) as set in PY_CFLAGS in
>> Makefile.pre.
Alexander Belopolsky wrote:
> On Sun, Jun 27, 2010 at 5:57 AM, Mark Dickinson wrote:
>> On Sun, Jun 27, 2010 at 10:41 AM, Georg Brandl wrote:
>>> So -- if every dev "adopted" a Tool or Demo, that would be quite a
>>> manageable piece of work, and maybe a few demos can be brought up
>>> to scratch
Brett Cannon wrote:
> On Sun, Jun 27, 2010 at 13:37, Jeffrey Yasskin wrote:
>> On Sun, Jun 27, 2010 at 1:04 PM, Mark Dickinson wrote:
>>> On Sun, Jun 27, 2010 at 6:46 AM, Jeffrey Yasskin wrote:
AC_PROG_CC is the macro that sets CFLAGS to -g -O2 on gcc-based
systems
(http://www.gn
Mark Dickinson wrote:
> On Mon, Jun 28, 2010 at 12:38 PM, M.-A. Lemburg wrote:
>>> On Sun, Jun 27, 2010 at 13:37, Jeffrey Yasskin wrote:
>>>> On Sun, Jun 27, 2010 at 1:04 PM, Mark Dickinson wrote:
>>>>> I'm not sure I understand the importance of
Mark Dickinson wrote:
> On Mon, Jun 28, 2010 at 3:04 PM, M.-A. Lemburg wrote:
>> Why do you think that the default -O2 is unwanted
>
> Because it can cause debug builds of Python to be built with
> optimization enabled, as we've already seen at least twice.
Then let m
M.-A. Lemburg wrote:
> Mark Dickinson wrote:
>> On Mon, Jun 28, 2010 at 3:04 PM, M.-A. Lemburg wrote:
>>> Why do you think that the default -O2 is unwanted
>>
>> Because it can cause debug builds of Python to be built with
>> optimization enabled, as we'
Mark Dickinson wrote:
> On Mon, Jun 28, 2010 at 4:28 PM, M.-A. Lemburg wrote:
>> Mark Dickinson wrote:
>>> On Mon, Jun 28, 2010 at 3:04 PM, M.-A. Lemburg wrote:
>>>> Why do you think that the default -O2 is unwanted
>>>
>>> Because it c
Barry Warsaw wrote:
> On Jun 25, 2010, at 12:35 AM, M.-A. Lemburg wrote:
>
>> Scott Dial wrote:
>>> On 6/24/2010 5:09 PM, Barry Warsaw wrote:
>>>>> What use case does this address?
>>>>
>>>>> If you want to make it so a system
Terry Reedy wrote:
> Comment on trust. Trust works both ways. So does distrust.
>
> Asking contributors to give written licenses in addition to the license
> implicit in the act of contribution is an act of distrust. It says
> something like "We worry that you might change you mind and sue, and a
Ronald Oussoren wrote:
>
> On 27 Jun, 2010, at 11:48, Greg Ewing wrote:
>
>> Stefan Behnel wrote:
>>> Greg Ewing, 26.06.2010 09:58:
Would there be any sanity in having an option to compile
Python with UTF-8 as the internal string representation?
>>> It would break Py_UNICODE, because th
Is this intended or should I open a bug report for it:
>>> m = memoryview('abc')
>>> m == 'abc'
True
>>> str(m) == 'abc'
False
>>> str(m)
''
I would have expected str(m) == 'abc'.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Jul 15 2010)
>>> Pyth
Nick Coghlan wrote:
> I wouldn't assume so - memoryview is meant to eventually support more
> than just 1-D views of contiguous memory (see PEP 3118), so that
> conversion doesn't seem intuitive to me.
In the example I'm passing in a single dimension contiguous memory
chunk to memoryview(), so in
Tarek Ziadé wrote:
> On Mon, Aug 2, 2010 at 3:06 AM, P.J. Eby wrote:
> ..
>>
>> So without specific examples of why this is a problem, it's hard to see why
>> a special Python-specific set of configuration files is needed to resolve
>> it, vs. say, encouraging application authors to use the availa
exar...@twistedmatrix.com wrote:
> On 12:21 pm, m...@egenix.com wrote:
>> Tarek Ziad� wrote:
>>> On Mon, Aug 2, 2010 at 3:06 AM, P.J. Eby wrote:
>>> ..
So without specific examples of why this is a problem, it's hard to
see why
a special Python-specific set of configuration fil
Michael Foord wrote:
> On 02/08/2010 13:31, exar...@twistedmatrix.com wrote:
>> On 12:21 pm, m...@egenix.com wrote:
>>> Tarek Ziad� wrote:
On Mon, Aug 2, 2010 at 3:06 AM, P.J. Eby wrote:
..
>
> So without specific examples of why this is a problem, it's hard to
> see why
301 - 400 of 1090 matches
Mail list logo
