On Wed, Mar 18, 2015 at 12:22:03PM -0400, Barry Warsaw wrote:
> On Mar 18, 2015, at 03:46 PM, Orion Poplawski wrote:
>
> >We're starting a discussion in Fedora about setting the default shbang for
> >system python executables and/or daemons to python -s or python -Es (or ?).
>
> We've talked abou
On Wed, Mar 18, 2015 at 2:56 PM, Barry Warsaw wrote:
> On Mar 18, 2015, at 02:44 PM, Toshio Kuratomi wrote:
>
>>Interesting, I've cautiously in favor of -s in Fedora but the more I've
>>thought about it the less I've liked -E. It just seems like PYTHONPATH is
>
apply to all scripts they run was
kind of lost in the followups (It wasn't directly addressed or
mentioned again.)
-Toshio
On Thu, Mar 19, 2015 at 12:27 PM, Barry Warsaw wrote:
> On Mar 19, 2015, at 11:15 AM, Toshio Kuratomi wrote:
>
>>I could see that as a difference. Ho
-Toshio
On Mar 19, 2015 3:27 PM, "Victor Stinner" wrote:
>
> 2015-03-19 21:47 GMT+01:00 Toshio Kuratomi :
> > I think I've found the Debian discussion (October 2012):
> >
> > http://comments.gmane.org/gmane.linux.debian.devel.python/8188
> >
> >
On Mon, Mar 23, 2015 at 03:30:23PM +0100, Antoine Pitrou wrote:
> On Mon, 23 Mar 2015 07:22:56 -0700
> Toshio Kuratomi wrote:
> >
> > Building off Nick's idea of a system python vs a python for users to use, I
> > would see a more useful modification to be abl
On Mon, Mar 23, 2015 at 04:14:52PM +0100, Antoine Pitrou wrote:
> On Mon, 23 Mar 2015 08:06:13 -0700
> Toshio Kuratomi wrote:
> > >
> > > I really think Donald has a good point when he suggests a specific
> > > virtualenv for system programs using Python.
>
On Tue, Apr 21, 2015 at 01:54:55PM -0400, Donald Stufft wrote:
>
> Anyways, I'll have access to the data set for another day or two before I
> shut down the (expensive) server that I have to use to crunch the numbers so
> if
> there's anything anyone else wants to see before I shut it down, speak
On Nov 7, 2017 5:47 AM, "Paul Moore" wrote:
On 7 November 2017 at 13:35, Philipp A. wrote:
> Sorry, I still don’t understand how any of this is a problem.
>
> If you’re an application developer, google “python disable
> DeprecationWarning” and paste the code you found, so your users don’t see
>
On Dec 9, 2017 8:53 PM, "INADA Naoki" wrote:
> Earlier versions of PEP 538 thus included "en_US.UTF-8" on the
> candidate target locale list, but that turned out to cause assorted
> problems due to the "C -> en_US" part of the coercion.
Hm, but PEP 538 says:
> this PEP instead proposes to exten
On Jan 13, 2018 9:08 AM, "Christian Heimes" wrote:
Hi,
PEP 370 [1] was my first PEP that got accepted. I created it exactly one
decade and two days ago for Python 2.6 and 3.0.
I didn't know I had you to thank for this! Thanks Christian! This is one
of the best features of the python software
On Fri, May 4, 2018, 7:00 PM Nathaniel Smith wrote:
> What are the obstacles to including "preloaded" objects in regular .pyc
> files, so that everyone can take advantage of this without rebuilding the
> interpreter?
>
Would this make .pyc files arch specific?
-Toshio
__
On Sat, May 5, 2018, 10:40 AM Eric Fahlgren wrote:
> On Sat, May 5, 2018 at 10:30 AM, Toshio Kuratomi
> wrote:
>
>> On Fri, May 4, 2018, 7:00 PM Nathaniel Smith wrote:
>>
>>> What are the obstacles to including "preloaded" objects in regular .pyc
>&g
On May 30, 2015 1:56 AM, "Nick Coghlan" wrote:
>
> Being ready, willing and able to handle the kind of situation created
> by the Python 2->3 community transition is a large part of what it
> means to offer commercial support for community driven open source
> projects, as it buys customers' time
On Nov 24, 2015 6:28 AM, "Laura Creighton" wrote:
>
> In a message of Tue, 24 Nov 2015 14:05:53 +, Paul Moore writes:
> >Simply adding "people who have no control over their broken
> >infrastructure" with a note that this PEP helps them, would be
> >sufficient here (and actually helps the case
On Mon, Nov 23, 2015 at 5:59 PM, Barry Warsaw wrote:
> I'm concerned about accepting PEP 493 making a strong recommendation to
> downstreams. Yes, in an ideal world we all want security by default, but I
> think the backward compatibility concerns of the PEP are understated,
> especially as they
On Tue, Nov 24, 2015 at 10:08 AM, Paul Moore wrote:
> I'm not actually sure that it's the place of this PEP to even comment
> on what the long term answer for such environments should be (or
> indeed, any answer, long term or not). I've argued the position that
> in some organisations it feels li
On Tue, Nov 24, 2015 at 10:56 AM, Paul Moore wrote:
> On 24 November 2015 at 18:37, Toshio Kuratomi wrote:
>> The cornercases come
>> into play because you don't always control all of the devices and
>> services on your network. The site could evaluate and decide that
On Nov 26, 2015 4:53 PM, "Nick Coghlan" wrote:
>
> On 27 November 2015 at 03:15, Barry Warsaw wrote:
>
> > Likewise in Ubuntu, we try to keep deviations from Debian at a minimum,
and
> > document them when we must deviate. Ubuntu is a community driven
distro so
> > while Canonical itself has cu
On Fri, Oct 25, 2013 at 01:32:36PM +1000, Nick Coghlan wrote:
>
> On 25 Oct 2013 09:02, "Terry Reedy" wrote:
>
> > http://lwn.net/Articles/571528/
> > https://fedoraproject.org/wiki/Changes/Python_3_as_Default
>
> Note that unlike Arch, the Fedora devs currently plan to leave "/usr/bin/
> pytho
On Tue, Jan 07, 2014 at 09:26:20PM +0900, Stephen J. Turnbull wrote:
> Is this really a good idea? PEP 460 proposes rather different
> semantics for bytes.format and the bytes % operator from the str
> versions. I think this is going to be both confusing and a continuous
> target for "further imp
On Thu, Nov 29, 2018, 6:56 AM Benjamin Peterson
>
> On Wed, Nov 28, 2018, at 15:27, Steven D'Aprano wrote:
> > On Wed, Nov 28, 2018 at 10:43:04AM -0800, Gregory P. Smith wrote:
> >
> > > PyPI makes getting more algorithms easy.
> >
> > Can we please stop over-generalising like this? PyPI makes get
On Tue, Feb 26, 2019 at 2:07 PM Neil Schemenauer
wrote:
> On 2019-02-26, Gregory P. Smith wrote:
> > On Tue, Feb 26, 2019 at 9:55 AM Barry Warsaw wrote:
> > For an OS distro provided interpreter, being able to restrict its use to
> > only OS distro provided software would be ideal (so ideal that
On Mon, Aug 5, 2019 at 6:47 PM wrote:
>
> I wish people with more product management experience would chime in;
> otherwise, 3.8 is going to ship with an intentional hard-to-ignore annoyance
> on the premise that we don't like the way people have been programming and
> that they need to change
On Sat, May 25, 2013 at 05:57:28PM +1000, Nick Coghlan wrote:
> On Sat, May 25, 2013 at 5:56 AM, Barry Warsaw wrote:
> > Have any other *nix distros addressed this, and if so, how do you solve it?
>
> I believe Fedora follows the lead set by our own makefile and just
> appends a "3" to the script
On Tue, May 28, 2013 at 01:22:01PM -0400, Barry Warsaw wrote:
> On May 27, 2013, at 11:38 AM, Toshio Kuratomi wrote:
>
> >- If upstream doesn't deal with it, then we use a "python3-" prefix. This
> >matches with our package naming so it seemed to make sense.
Note: I'm the opposite number to bkabrda in the discussion on the Fedora
Lists about how quickly we should be breaking end-user expectations of what
"python" means.
On Wed, Jul 24, 2013 at 09:34:11AM -0400, Brett Cannon wrote:
>
>
>
> On Wed, Jul 24, 2013 at 5:12 AM, Bohuslav Kabrda wrote:
>
On Wed, Jul 24, 2013 at 12:42:09PM -0400, Barry Warsaw wrote:
> On Jul 25, 2013, at 01:41 AM, Nick Coghlan wrote:
>
> >How's this for an updated wording in the abstract:
> >
> > * for the time being, all distributions should ensure that python
> >refers to the same target as python2
> > * howeve
On Jul 24, 2013 6:37 AM, "Brett Cannon" wrote:
> The key, though, is adding python2 and getting your code to use that
binary specifically so that shifting the default name is more of a
convenience than something which might break existing code not ready for
the switch.
>
Applicable to this, does
On Thu, Jul 25, 2013 at 10:25:26PM +1000, Nick Coghlan wrote:
> On 25 July 2013 20:38, Toshio Kuratomi wrote:
> >
> > On Jul 24, 2013 6:37 AM, "Brett Cannon" wrote:
> >> The key, though, is adding python2 and getting your code to use that
> >> binary
On Thu, Sep 05, 2013 at 02:53:43PM -0400, Barry Warsaw wrote:
>
> This probably isn't the only application of these technologies, but I've
> always thought about OAuth as delegating authority to scripts and programs to
> act on your behalf. For example, you can write a script to interact with
> L
On Thu, Sep 05, 2013 at 10:25:22PM +0400, Oleg Broytman wrote:
> On Thu, Sep 05, 2013 at 02:16:29PM -0400, Donald Stufft
> wrote:
> >
> > On Sep 5, 2013, at 2:12 PM, Oleg Broytman wrote:
> > > I used to use myOpenID and became my own provider using poit[1].
> > > These days I seldom use OpenI
On Thu, Sep 5, 2013 at 6:09 PM, Stephen J. Turnbull wrote:
> Barry Warsaw writes:
> > We're open source, and I think it benefits our mission to support open,
> > decentralized, and free systems like OpenID and Persona.
>
> Thus speaks an employee of yet another Provider-That-Won't-Accept-My-
>
On Tue, Oct 15, 2013 at 03:46:15PM +0200, "Martin v. Löwis" wrote:
> Am 15.10.13 14:49, schrieb Daniel Holth:
> > It is part of the ZIP specification. CP437 or UTF-8 are the two
> > official choices, but other encodings happen on Russian, Japanese
> > systems.
>
> Indeed. Formally, the other encod
On Jun 14, 2016 8:32 AM, "Joao S. O. Bueno" wrote:
>
> On 14 June 2016 at 12:19, Steven D'Aprano wrote:
> > Is there
> > a good reason for returning bytes?
>
> What about: it returns 0-255 numeric values for each position in a
stream, with
> no clue whatsoever to how those values map to text cha
On Sat, Mar 4, 2017 at 11:50 PM, Nick Coghlan wrote:
>
> Providing implicit locale coercion only when running standalone
> ---
>
> Over the course of Python 3.x development, multiple attempts have been made
> to improve the handling of in
This is an excellent enumeration of some of the concerns!
One minor comment about the introductory material:
On Mon, Nov 1, 2021 at 5:21 AM Petr Viktorin wrote:
> >
> > Introduction
> >
> >
> > Python code is written in `Unicode`_ – a system for encoding and
> > handling all kinds
On Sun, Mar 27, 2022, 11:07 AM Paul Moore wrote:
> On Sun, 27 Mar 2022 at 17:11, Christopher Barker
> wrote:
> > Back to the topic at hand, rather than remove urllib, maybe it could be
> made better -- an as-easy-to-use-as-requests package in the stdlib would be
> really great.
>
> I think that'
On Tue, Mar 29, 2022, 10:55 AM Brett Cannon wrote:
>
>
> On Tue, Mar 29, 2022 at 8:58 AM Ronald Oussoren
> wrote:
>
>>
>>
>> On 29 Mar 2022, at 00:34, Brett Cannon wrote:
>>
>>
>>
>> On Mon, Mar 28, 2022 at 11:52 AM Christopher Barker
>> wrote:
>>
>>> On Mon, Mar 28, 2022 at 11:29 AM Paul Moor
On Fri, Oct 9, 2020, 5:30 AM Christian Heimes wrote:
> On 09/10/2020 04.04, Ivan Pozdeev via Python-Dev wrote:
> > I don't see the point of requiring to "write an apology", especially
> > *before a 12-month ban*. If they understand that their behavior is
> > wrong, there's no need for a ban, at l
Antoine Pitrou wrote:
> Steven D'Aprano pearwood.info> writes:
>> It depends on what you mean by "temporary".
>>
>> Applications like OpenOffice can sometimes recover from an application
>> crash or even a systems crash and give you the opportunity to restore
>> the temporary files that were lef
Martin v. Löwis wrote:
>> Something that doesn't require deterministicly named tempfiles was Ted
>> T'so's explanation linked to earlier.
>>
>> read data from important file
>> modify data
>> create tempfile
>> write data to tempfile
>> *sync tempfile to disk*
>> mv tempfile to filename of importan
Martin v. Löwis wrote:
The sync is necessary to ensure that the data is written to the disk
before the old file overwrites the new filename.
>>> You still wouldn't use the tempfile module in that case. Instead, you
>>> would create a regular file, with the name base on the name of the
>>>
Martin v. Löwis wrote:
>> auto-delete is one of the nice features of tempfile. Another feature
>> which is entirely appropriate to this usage, though, though, is creation
>> of a non-conflicting filename.
>
> Ok. In that use case, however, it is completely irrelevant whether the
> tempfile module
Stephen J. Turnbull wrote:
> Chris Withers writes:
>
> > - debian has an outdated and/or broken version of your package.
>
> True, but just as for the package system you are advocating, it's
> quite easy to set up your apt to use third-party repositories of
> Debian-style packages. The question i
Steve Holden wrote:
> Seems to me that while all this is fine for developers and Python users
> it's completely unsatisfactory for people who just want to use Python
> applications. For them it's much easier if each application comes with
> all dependencies including the interpreter.
>
> This may
David Cournapeau wrote:
> 2009/3/24 Toshio Kuratomi :
>> Steve Holden wrote:
>>
>>> Seems to me that while all this is fine for developers and Python users
>>> it's completely unsatisfactory for people who just want to use Python
>>> applications
Tres Seaver wrote:
> David Cournapeau wrote:
>>> I am afraid that distutils, and
>>> setuptools, are not really the answer to the problem, since while they
>>> may (as intended) guarantee that Python applications can be installed
>>> uniformly across different platforms they also more or less guara
David Cournapeau wrote:
> On Wed, Mar 25, 2009 at 1:45 AM, Toshio Kuratomi
wrote:
>> David Cournapeau wrote:
>>> 2009/3/24 Toshio Kuratomi :
>>>> Steve Holden wrote:
>>>>
>>>>> Seems to me that while all this is fine for developers and Pyt
Barry Warsaw wrote:
> Tools like setuptools, zc.buildout, etc. seem great for developers but
> not very good for distributions. At last year's Pycon I think there was
> agreement from the Linux distributors that distutils, etc. just wasn't
> very useful for them.
>
It's decent for modules but ha
David Cournapeau wrote:
>> I won't argue for setuptools' implementation of multi-version. It
>> sucks. But multi-version can be done well. Sonames in C libraries are
>> a simple system that does this better.
>
> I would say simplistic instead of simple :) what works for C won't
> necessarily wo
Guido van Rossum wrote:
> On Wed, Mar 25, 2009 at 9:40 PM, Tarek Ziadé wrote:
>> I think Distutils (and therefore Setuptools) should provide some APIs
>> to play with special files (like resources) and to mark them as being
>> special,
>> no matter where they end up in the target system.
>>
>> So
Guido van Rossum wrote:
> 2009/3/26 Toshio Kuratomi :
>> Guido van Rossum wrote:
>>> On Wed, Mar 25, 2009 at 9:40 PM, Tarek Ziadé wrote:
>>>> I think Distutils (and therefore Setuptools) should provide some APIs
>>>> to play with special files
Robert Collins wrote:
> Certainly, import time is part of it:
> robe...@lifeless-64:~$ python -m timeit -s 'import sys; import
> bzrlib.errors' "del sys.modules['bzrlib.errors']; import bzrlib.errors"
> 10 loops, best of 3: 18.7 msec per loop
>
> (errors.py is 3027 lines long with 347 exception
Greg Ewing wrote:
> Steven Bethard wrote:
>
>> That's an unfortunate decision. When the 2.X line stops being
>> maintained (after 2.7 maybe?) we're going to be stuck with the "3"
>> suffix forever for the "real" Python.
>
> I don't see why we have to be stuck with it forever.
> When 2.x has faded
Glenn Linderman wrote:
> On approximately 4/24/2009 11:40 AM, came the following characters from
> And so my encoding (1) doesn't alter the data stream for any valid
> Windows file name, and where the naivest of users reside (2) doesn't
> alter the data stream for any Posix file name that was encod
Terry Reedy wrote:
> Is NUL \0 allowed in POSIX file names? If not, could that be used as an
> escape char. If it is not legal, then custom translated strings that
> escape in the wild would raise a red flag as soon as something else
> tried to use them.
>
AFAIK NUL should be okay but I haven't
Zooko O'Whielacronx wrote:
> On Apr 28, 2009, at 6:46 AM, Hrvoje Niksic wrote:
>> If you switch to iso8859-15 only in the presence of undecodable UTF-8,
>> then you have the same round-trip problem as the PEP: both b'\xff' and
>> b'\xc3\xbf' will be converted to u'\u00ff' without a way to
>> unambi
Martin v. Löwis wrote:
>> Since the serialization of the Unicode string is likely to use UTF-8,
>> and the string for such a file will include half surrogates, the
>> application may raise an exception when encoding the names for a
>> configuration file. These encoding exceptions will be as rare a
Thomas Breuel wrote:
> Not for me (I am using Python 2.6.2).
>
> >>> f = open(chr(255), 'w')
> Traceback (most recent call last):
> File "", line 1, in
> IOError: [Errno 22] invalid mode ('w') or filename: '\xff'
> >>>
>
>
> You can get the same error on Linux:
>
> $ p
On 09/23/2009 10:00 AM, Tarek Ziadé wrote:
> But you are right about the need of making sure every package management
> project is involved. We should make sure that Enthought,
> which has its own package management system, is part of that consensus.
>
> Also, I am more concerned of not having en
On 09/29/2009 04:38 PM, Steven Bethard wrote:
> On Tue, Sep 29, 2009 at 3:04 PM, Glenn Linderman
> wrote:
>> On approximately 9/29/2009 1:57 PM, came the following characters from the
>> keyboard of Steven Bethard:
>>> If you're not using argparse to write command line applications, then
>>> I do
On Thu, Oct 08, 2009 at 01:27:57PM +0200, M.-A. Lemburg wrote:
> > Tarek Ziadé a écrit :
> >> But if PEP 376 and PEP 386 support are added in Python, we're not far
> >> from being able to provide multiple version support with
> >> the help of importlib.
>
> Before putting much work into this: do y
On Thu, Oct 08, 2009 at 02:52:24PM +0200, Simon Cross wrote:
> On Thu, Oct 8, 2009 at 10:31 AM, Tarek Ziadé wrote:
> > = Virtualenv and the multiple version support in Distribute =
> ...
> > My opinion is that this tool exists only because Python doesn't
> > support the installation of multiple v
On Thu, Oct 08, 2009 at 06:56:19PM +0200, kiorky wrote:
>
>
> Toshio Kuratomi a écrit :
> >
> > Also note, the ability to have multiple versions makes things easier for
> > system packagers and provides an easy alternative to a virtualenv for
> > end-u
On Thu, Oct 08, 2009 at 04:28:52PM +, Antoine Pitrou wrote:
> Toshio Kuratomi gmail.com> writes:
> >
> > This is needing to install multiple versions and use the newly installed
> > version for testing.
> [...]
>
> What you're missing is that having
On Thu, Oct 08, 2009 at 05:30:00PM +0100, Michael Foord wrote:
> Toshio Kuratomi wrote:
>> On Thu, Oct 08, 2009 at 02:52:24PM +0200, Simon Cross wrote:
>>
>>> On Thu, Oct 8, 2009 at 10:31 AM, Tarek Ziadé wrote:
>>>
>>>> = Virtualenv a
On Fri, Oct 09, 2009 at 04:51:00PM +0100, Chris Withers wrote:
> Tarek Ziadé wrote:
>> Virtualenv allows you to create an isolated environment to install
>> some distribution without polluting the
>> main site-packages, a bit like a user site-packages.
>
> ...as does buildout, and these are the rig
On Fri, Oct 09, 2009 at 05:29:28PM +0100, Chris Withers wrote:
> Toshio Kuratomi wrote:
>> On Fri, Oct 09, 2009 at 04:51:00PM +0100, Chris Withers wrote:
>>> Tarek Ziadé wrote:
>>>> Virtualenv allows you to create an isolated environment to install
>>>&g
On Sun, Nov 15, 2009 at 02:31:45PM +0100, Georg Brandl wrote:
> Antoine Pitrou schrieb:
> > Tarek Ziadé gmail.com> writes:
> >>
> >> This cannot work on all platforms, when our Makefile is not shipped
> >> with python but python-devel. (like Fedora)
> >
> > This practice is stupid anyway, becaus
On Thu, Jan 21, 2010 at 12:25:59PM +, Antoine Pitrou wrote:
> > We seek guidance from the community on
> > an acceptable level of increased memory usage.
>
> I think a 10-20% increase would be acceptable.
>
I'm just a user of the core interpreter but the bottleneck in using python
in my envir
On Thu, Jan 21, 2010 at 09:32:23AM -0800, Collin Winter wrote:
> Hi Dirkjan,
>
> On Wed, Jan 20, 2010 at 10:55 PM, Dirkjan Ochtman wrote:
> > For some apps (like Mercurial, which I happen to sometimes hack on),
> > increased startup time really sucks. We already have our demandimport
> > code (I
On Wed, Feb 17, 2010 at 09:15:25AM +0700, Stuart Bishop wrote:
>
> The Debian, Ubuntu and I think Redhat packages all use the system
> zoneinfo database - there are hooks in there to support package
> maintainers that want to do this.
Where RedHat == Fedora && EPEL packages for RHEL/Centos 5, yes
On Mon, Apr 26, 2010 at 05:46:55PM -0400, Barry Warsaw wrote:
> On Apr 26, 2010, at 09:39 PM, Tarek Ziadé wrote:
>
> >You should be permissive on that one. Until we know how to describe resource
> >files properly, __file__ is what developer use when they need their projects
> >to be portable..
>
On Tue, Apr 27, 2010 at 09:41:02AM +0200, Tarek Ziadé wrote:
> On Tue, Apr 27, 2010 at 1:24 AM, Toshio Kuratomi wrote:
> > On Mon, Apr 26, 2010 at 05:46:55PM -0400, Barry Warsaw wrote:
> >> On Apr 26, 2010, at 09:39 PM, Tarek Ziadé wrote:
> >>
> >> >You sho
On Mon, Jun 21, 2010 at 09:57:30AM -0400, Barry Warsaw wrote:
> On Jun 21, 2010, at 09:37 AM, Arc Riley wrote:
>
> >Also, under where it mentions that most OS's do not include Python 3, it
> >should be noted which have good support for it. Gentoo (for example) has
> >excellent support for Python
On Mon, Jun 21, 2010 at 11:43:07AM -0400, Barry Warsaw wrote:
> On Jun 21, 2010, at 10:20 PM, Nick Coghlan wrote:
>
> >Something that may make sense to ease the porting process is for some
> >of these "on the boundary" I/O related string manipulation functions
> >(such as os.path.join) to grow "en
On Tue, Jun 22, 2010 at 01:08:53AM +0900, Stephen J. Turnbull wrote:
> Lennart Regebro writes:
>
> > 2010/6/21 Stephen J. Turnbull :
> > > IMO, the UI is right. "Something" like the above "ought" to work.
> >
> > Right. That said, many times when you want to do urlparse etc they
> > might b
On Mon, Jun 21, 2010 at 01:24:10PM -0400, P.J. Eby wrote:
> At 12:34 PM 6/21/2010 -0400, Toshio Kuratomi wrote:
> >What do you think of making the encoding attribute a mandatory part of
> >creating an ebyte object? (ex: ``eb = ebytes(b, 'euc-jp')``).
>
> As long
On Mon, Jun 21, 2010 at 02:46:57PM -0400, P.J. Eby wrote:
> At 02:58 AM 6/22/2010 +0900, Stephen J. Turnbull wrote:
> >Nick alluded to the The One Obvious Way as a change in architecture.
> >
> >Specifically: Decode all bytes to typed objects (str, images, audio,
> >structured objects) at input. D
On Mon, Jun 21, 2010 at 04:09:52PM -0400, P.J. Eby wrote:
> At 03:29 PM 6/21/2010 -0400, Toshio Kuratomi wrote:
> >On Mon, Jun 21, 2010 at 01:24:10PM -0400, P.J. Eby wrote:
> >> At 12:34 PM 6/21/2010 -0400, Toshio Kuratomi wrote:
> >> >What do you think of making the
On Mon, Jun 21, 2010 at 04:52:08PM -0500, John Arbash Meinel wrote:
>
> ...
> >> IOW, if you're producing output that has to go into another system
> >> that doesn't take unicode, it doesn't matter how
> >> theoretically-correct it would be for your app to process the data in
> >> unicode form. I
On Tue, Jun 22, 2010 at 11:58:57AM +0900, Stephen J. Turnbull wrote:
> Toshio Kuratomi writes:
>
> > One comment here -- you can also have uri's that aren't decodable into
> their
> > true textual meaning using a single encoding.
> >
> > Apache
On Tue, Jun 22, 2010 at 08:31:13PM +0900, Stephen J. Turnbull wrote:
> Toshio Kuratomi writes:
> > unicode handling redesign. I'm stating my reading of the RFC not to defend
> > the use case Philip has, but because I think that the outlook that non-text
> > uris (b
On Tue, Jun 22, 2010 at 08:24:28AM -0500, Michael Urman wrote:
> On Tue, Jun 22, 2010 at 00:28, Stephen J. Turnbull wrote:
> > Michael Urman writes:
> >
> > > It is somewhat troublesome that there doesn't appear to be an obvious
> > > built-in idempotent-when-possible function that gives back th
On Wed, Jun 23, 2010 at 09:36:45PM +0200, Antoine Pitrou wrote:
> On Wed, 23 Jun 2010 14:23:33 -0400
> Tres Seaver wrote:
> > - - the slow adoption / porting rate of major web frameworks and libraries
> > to Python 3.
>
> Some of the major web frameworks and libraries have a ton of
> dependenci
On Wed, Jun 23, 2010 at 11:35:12PM +0200, Antoine Pitrou wrote:
> On Wed, 23 Jun 2010 17:30:22 -0400
> Toshio Kuratomi wrote:
> > Note that this assumption seems optimistic to me. I started talking to
> > Graham
> > Dumpleton, author of mod_wsgi a couple years back be
On Tue, Jul 06, 2010 at 10:10:09AM +0300, Nir Aides wrote:
> I take "...running off with the good stuff and selling it for profit" to mean
> "creating derivative work and commercializing it as proprietary code" which
> you
> can not do with GPL licensed code. Also, while the GPL does not prevent
On Fri, Aug 13, 2010 at 07:48:22AM +1000, Nick Coghlan wrote:
> 2010/8/12 Éric Araujo :
> >> Choosing an arbitrary location we think is good on every system is fine
> >> and non risky I think, as long as Python let the various distribution
> >> change those paths though configuration.
> >
> > Don’t
On Fri, Aug 13, 2010 at 03:15:28AM +0200, Éric Araujo wrote:
> > A good alternative would be to make the config file overridable. That way
> > you can have sysconfig.cfg next to sysconfig.py or in a known config
> > directory relative to the python stdlib install but also let the
> > distributions
On Thu, Sep 16, 2010 at 09:52:48AM -0400, Barry Warsaw wrote:
> On Sep 16, 2010, at 11:28 PM, Nick Coghlan wrote:
>
> >There are some APIs that should be able to handle bytes *or* strings,
> >but the current use of string literals in their implementation means
> >that bytes don't work. This turns
On Thu, Sep 16, 2010 at 10:56:56AM -0700, Guido van Rossum wrote:
> On Thu, Sep 16, 2010 at 10:46 AM, Martin (gzlist)
> wrote:
> > On 16/09/2010, Guido van Rossum wrote:
> >>
> >> In all cases I can imagine where such polymorphic functions make
> >> sense, the necessary and sufficient assumption
On Wed, Sep 29, 2010 at 01:23:24PM -0700, Guido van Rossum wrote:
> On Wed, Sep 29, 2010 at 1:12 PM, Brett Cannon wrote:
> > On Wed, Sep 29, 2010 at 12:03, Guido van Rossum wrote:
> >> A problem with that is that we regularly make matching improvements to
> >> upload.py and the server-side code i
On Fri, Oct 08, 2010 at 10:26:36AM -0400, Barry Warsaw wrote:
> On Oct 08, 2010, at 03:22 PM, Tarek Ziadé wrote:
>
> >Yes that what I was thinking about -- I am not too worried about this,
> >since every Linux deals with the 'more than one python installed'
> >case.
>
> Kind of. but anyway...
On Fri, Oct 08, 2010 at 05:12:44PM +0200, Antoine Pitrou wrote:
> On Fri, 8 Oct 2010 11:04:35 -0400
> Toshio Kuratomi wrote:
> >
> > In the larger universe of programs, it might make for more intuitive
> > remembering of the command to use a prefix (either py or python)
On Thu, Oct 21, 2010 at 12:00:40PM -0400, Barry Warsaw wrote:
> On Oct 20, 2010, at 02:11 AM, Victor Stinner wrote:
>
> >I plan to fix Python documentation: specify the encoding used to decode all
> >byte string arguments of the C API. I already wrote a draft patch: issue
> >#9738. This lack of
On Fri, Oct 29, 2010 at 11:12:28AM -0700, geremy condra wrote:
> On Thu, Oct 28, 2010 at 11:55 PM, Glyph Lefkowitz
> > Let's take PyPI numbers as a proxy. There are ~8000 packages with a
> > "Programming Language::Python" classifier. There are ~250 with "Programming
> > Langauge::Python::3". Rou
On Tue, Nov 09, 2010 at 11:46:59AM +1100, Ben Finney wrote:
> Ron Adam writes:
>
> > def _publicly_documented_private_api():
> > """ Not sure why you would want to do this
> > instead of using comments.
> > """
> > ...
>
> Because the docstring is available at the interpret
On Tue, Nov 09, 2010 at 01:49:01PM -0500, Tres Seaver wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 11/08/2010 06:26 PM, Bobby Impollonia wrote:
>
> > This does hurt because anyone who was relying on "import *" to get a
> > name which is now omitted from __all__ is going to upgr
On Wed, Dec 01, 2010 at 10:06:24PM -0500, Alexander Belopolsky wrote:
> On Wed, Dec 1, 2010 at 9:53 PM, Terry Reedy wrote:
> ..
> > Does Sphinx run on PY3 yet?
>
> It does, but see issue10224 for details.
>
> http://bugs.python.org/issue10224
>
Also, docutils has an unported module.
/me needs
On Fri, Dec 03, 2010 at 11:52:41PM +0100, "Martin v. Löwis" wrote:
> Am 03.12.2010 23:48, schrieb Éric Araujo:
> >> But I'm not interested at all in having it in distutils2. I want the
> >> Python build itself to use it, and alas, I can't because of the freeze.
> > You can’t in 3.2, true. Neither
1 - 100 of 170 matches
Mail list logo
