Re: [Python-Dev] Using logging in the stdlib and its unit tests

On 12/10/2010 9:06 PM, Nick Coghlan wrote: Anyway, the shortest way I could find of setting this up (debug silenced, info written to stdout, warning and above written to stderr): import sys, logging root = logging.getLogger() # Turns out the level of the root logger is set to WARNING by

Re: [Python-Dev] Using logging in the stdlib and its unit tests

On 12/11/2010 12:00 AM, Nick Coghlan wrote: On Sat, Dec 11, 2010 at 4:25 PM, Glenn Linderman wrote: On 12/10/2010 9:24 PM, Nick Coghlan wrote: This could actually make a reasonably good basic for a "task oriented" subsection of the logging documentation. Something like: Yep, agree.

Re: [Python-Dev] Using logging in the stdlib and its unit tests

On 12/11/2010 1:28 AM, Vinay Sajip wrote: Nick Coghlan gmail.com> writes: The "lazy" stream handler might be useful to make public in some way. For example, rather than hardcoding sys.stderr, it could take a callable that it uses to retrieve the stream. That kind of change can wait until 3.3 t

Re: [Python-Dev] Using logging in the stdlib and its unit tests

On 12/11/2010 1:07 AM, Nick Coghlan wrote: As Glenn mentioned later in the thread, the output of logging.info and logging.debug messages is*distinct* from an application's normal operational output that is emitted on stdout. So making it easy to emit such messages on stderr is the right thing to

Re: [Python-Dev] Using logging in the stdlib and its unit tests

On 12/11/2010 3:52 AM, Vinay Sajip wrote: I will try to incorporate more basic examples at the top of the documentation, but surely you don't want me to add more verbiage about basicConfig when your overall feeling is that there's too much documentation? I try not to post unless I feel there is

Re: [Python-Dev] Using logging in the stdlib and its unit tests

On 12/12/2010 2:26 PM, Paul Moore wrote: The thing*I* hit very early was wanting to add a command lime option to my script to set the logging level. I'd have liked to be able to add --log=INFO/DEBUG/... but to do that I seem to need to write my own mapping between level names and numbers. A simp

Re: [Python-Dev] Using logging in the stdlib and its unit tests

On 12/12/2010 9:41 AM, Vinay Sajip wrote: Gosh, Nick, that was fast! I'm still making changes, but thanks for spotting and highlighting the typos and omissions. I've just checked in a further update; hopefully it'll get built soon so we can all see the latest changes. I'm not as fast as Nick, b

Re: [Python-Dev] A grammatical oddity: trailing commas in argument lists -- continuation

On 12/13/2010 11:17 AM, Antoine Pitrou wrote: On Mon, 13 Dec 2010 14:09:02 -0500 Alexander Belopolsky wrote: On Mon, Dec 13, 2010 at 11:54 AM, Guido van Rossum wrote: I'm at least +0 on allowing trailing commas in the situation the OP mentioned. FWIW, I am also about +0.5 on allowing trail

Re: [Python-Dev] A grammatical oddity: trailing commas in argument lists -- continuation

On 12/13/2010 11:39 AM, Mark Dickinson wrote: my_thing = Thing( foo = Foo(arg1, arg2, ...), bar = Bar(arg3, arg4, ...), ... ) and I've found the trailing comma very convenient during refactoring and API experimentation. (There's still good fun to be had arguing about the indentat

Re: [Python-Dev] A grammatical oddity: trailing commas in argument lists -- continuation

On 12/13/2010 1:55 PM, Raymond Hettinger wrote: It seems to me that a trailing comma in an argument list is more likely to be a user error than a deliberate comma-for-the-future. It seems to me that a trailing comma, especially in the case of one parameter per line, is a deliberate comma-for-

Re: [Python-Dev] Remove HTTP 0.9 support

On 12/15/2010 10:39 AM, Antoine Pitrou wrote: Hello, I would like to remove HTTP 0.9 support from http.client and http.server. I've opened an issue at http://bugs.python.org/issue10711 for that. Would anyone think it's a bad idea? (HTTP 1.0 was devised in 1996) Please address the following co

Re: [Python-Dev] Remove HTTP 0.9 support

On 12/15/2010 1:25 PM, Antoine Pitrou wrote: On Wed, 15 Dec 2010 12:58:51 -0800 Glenn Linderman wrote: On 12/15/2010 10:39 AM, Antoine Pitrou wrote: Hello, I would like to remove HTTP 0.9 support from http.client and http.server. I've opened an issue at http://bugs.python.org/issue1071

Re: [Python-Dev] A grammatical oddity: trailing commas in argument lists -- continuation

On 12/18/2010 1:04 PM, Georg Brandl wrote: Am 13.12.2010 21:08, schrieb Glenn Linderman: On 12/13/2010 11:39 AM, Mark Dickinson wrote: my_thing = Thing( foo = Foo(arg1, arg2, ...), bar = Bar(arg3, arg4, ...), ... ) and I've found the trailing comma very convenient d

Re: [Python-Dev] r87389 - in python/branches/py3k: Doc/library/unittest.rst Lib/unittest/case.py Misc/NEWS

On 12/20/2010 6:31 AM, Antoine Pitrou wrote: > Diffing is completely an implementation detail of how the failure > messages are generated. The important thing is that failure messages > make sense with respect to actual result and expected result. Which, again, they don't. Let's see: se

Re: [Python-Dev] r87389 - in python/branches/py3k: Doc/library/unittest.rst Lib/unittest/case.py Misc/NEWS

On 12/21/2010 4:17 AM, Michael Foord wrote: Glenn Linderman wants (actual, expected) and diffing to follow that If you say that is what I said, fine. I might not have understood the example well enough to say the right thing. I liked Nick's explanation, using the actual and expected

Re: [Python-Dev] Column offsets for attribute nodes

On 12/26/2010 1:41 PM, Sven Brauch wrote: Hi there, I recently filed a feature request in the tracker to change the behaviour of the parser in terms of setting ranges on attribute AST nodes, because I'm working on an application which needs more information than is currently provided. I suggeste

Re: [Python-Dev] Loggers in the stdlib and logging configuration APIs

On 12/27/2010 7:29 AM, Vinay Sajip wrote: The logging configuration calls fileConfig and dictConfig disable all existing loggers, and enable only loggers explicitly named in the configuration (and their children). Although there is a disable_existing_loggers option for each configuration API, whi

Re: [Python-Dev] Loggers in the stdlib and logging configuration APIs

On 12/27/2010 11:53 PM, Nick Coghlan wrote: However, rather than a manually maintained list of low level loggers, Yes, a manually maintained list would be bad. it may be feasible to just have a flag we can set on loggers that makes them immune to the default implicit disabling. Then the confi

Re: [Python-Dev] Loggers in the stdlib and logging configuration APIs

On 12/28/2010 12:19 AM, Vinay Sajip wrote: > calls can support three levels of logger disabling: > - leave all existing loggers enabled (existing option) I think you mean disabled - that's the current behaviour. > - leave only flagged loggers enabled (new default behaviour) > - disable all

Re: [Python-Dev] Loggers in the stdlib and logging configuration APIs

On 12/28/2010 4:16 AM, Vinay Sajip wrote: How does that sound? Sounds pretty rational, overall. If the leave_enabled flag can be turned on/off by the application, then I agree the arms race is unlikely. I didn't dig through the logging docs to discover if there is an API that returns a lis

Re: [Python-Dev] PEP 3333: wsgi_string() function

On 1/6/2011 3:50 PM, And Clover wrote: ISO-8859-1 is the encoding specified by the HTTP RFC Please could I have the reference to that specification? I only recall ASCII and UTF-8 in my readings of various things HTTP and HTML, for headers, and form data. Naturally data pages can have any en

Re: [Python-Dev] PEP 3333: wsgi_string() function

On 1/6/2011 7:37 PM, Stephen J. Turnbull wrote: Glenn Linderman writes: > On 1/6/2011 3:50 PM, And Clover wrote: > > ISO-8859-1 is the encoding specified by the HTTP RFC > > Please could I have the reference to that specification? RFC 2616 (probably obsolete by now, b

Re: [Python-Dev] Import and unicode: part two

On 1/19/2011 11:31 AM, Victor Stinner wrote: If we decide to reject non-ASCII module names, it should be done on any operating systems, not only on Windows. Since Python allows non-ASCII variable names, I think it should allow non-ASCII module names also, on any platform that supports the app

Re: [Python-Dev] Import and unicode: part two

On 1/19/2011 8:39 PM, Toshio Kuratomi wrote: use this:: import cafe as café When you do things this way you do not have to translate between unknown encodings into unicode. Everything is within python source where you have a defined encoding. This is a great way of converting non-portable

Re: [Python-Dev] Import and unicode: part two

On 1/19/2011 9:11 PM, Glyph Lefkowitz wrote: On Jan 20, 2011, at 12:02 AM, Glenn Linderman wrote: But for local code, having to think up an ASCII name for a module rather than use the obvious native-language name, is just brain-burden when creating the code. Is it really? You already had

Re: [Python-Dev] Import and unicode: part two

On 1/19/2011 11:20 PM, Toshio Kuratomi wrote: On Wed, Jan 19, 2011 at 09:02:17PM -0800, Glenn Linderman wrote: On 1/19/2011 8:39 PM, Toshio Kuratomi wrote: use this:: import cafe as café When you do things this way you do not have to translate between unknown encodings

Re: [Python-Dev] Import and unicode: part two

On 1/20/2011 12:27 PM, Glyph Lefkowitz wrote: To support the latter, could we just make sure that zipimport has a consistent, non-locale-or-operating-system-dependent interpretation of encoding? That way a distributed egg would be importable from a zipfile regardless of how screwed up the distri

Re: [Python-Dev] Import and unicode: part two

On 1/26/2011 4:47 PM, Toshio Kuratomi wrote: There's one further case that I am worried about that has no real "transfer". Since people here seem to think that unicode module names are the future (for instance, the comments about redefining the C locale to include utf-8 and the comments about ar

Re: [Python-Dev] PEP 393: Flexible String Representation

On 1/27/2011 12:26 PM, James Y Knight wrote: On Jan 27, 2011, at 2:06 PM, Stefan Behnel wrote: "Martin v. Löwis", 24.01.2011 21:17: The Py_UNICODE type is still supported but deprecated. It is always defined as a typedef for wchar_t, so the wstr representation can double as Py_UNICODE represent

Re: [Python-Dev] Support the /usr/bin/python2 symlink upstream

On 3/4/2011 5:21 AM, Nick Coghlan wrote: On Fri, Mar 4, 2011 at 10:59 PM, Michael Foord wrote: Should any of this also apply to Mac OS X and Windows? Any platform that considers itself "unix-like" in this context can decide to follow it, we aren't fussy (e.g. Cygwin and the *nix-y aspects of

Re: [Python-Dev] Support the /usr/bin/python2 symlink upstream

On 3/4/2011 1:35 PM, "Martin v. Löwis" wrote: I'd still like the PEP to tell me whether it's python3w.exe or pythonw3.exe (and yes, that's bikeshedding - so somebody just tell me). It would also be good if the PEP took a position on providing pythonXY.exe binaries on Windows (with the related que

Re: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink upstream

On 3/6/2011 7:07 AM, Michael Urman wrote: I think Glenn Linderman hit the use cases on the head; I'm unclear why he was against the overhead of a helper executable. The things I would really want solutions for are these: * double click on a script, and have it launch the right python (2

Re: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink upstream

On 3/7/2011 4:00 PM, Michael Foord wrote: On 07/03/2011 23:52, Greg Ewing wrote: Michael Foord wrote: - I doubt calling it python.exe will fly, but I'm not sure. If so what will you call what is currently 'python.exe'? - if not then "python foo.py" on the command line will *still* not wor

Re: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink upstream

On 3/7/2011 2:18 PM, James Y Knight wrote: On Mar 7, 2011, at 3:49 PM, Paul Moore wrote: > The launcher could also (as per Mark's suggestion) interpret a shebang > line in the script, so that scripts could specify their required > version without needing a different command,or multiple > ver

Re: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink upstream

On 3/8/2011 12:02 PM, Terry Reedy wrote: On 3/7/2011 9:31 PM, Reliable Domains wrote: The launcher need not be called "python.exe", and maybe it would be better called #@launcher.exe (or similar, depending on its exact function details). I do not know that the '#@' part is about, but pygo wou

Re: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink upstream

On 3/8/2011 8:02 PM, Toshio Kuratomi wrote: On Tue, Mar 08, 2011 at 06:43:19PM -0800, Glenn Linderman wrote: On 3/8/2011 12:02 PM, Terry Reedy wrote: On 3/7/2011 9:31 PM, Reliable Domains wrote: The launcher need not be called "python.exe", and maybe it would be

Re: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink upstream

On 3/8/2011 9:06 PM, Mark Hammond wrote: On 9/03/2011 1:43 PM, Glenn Linderman wrote: I'm of the opinion that attempting to parse a Unix #! line, and intuit what would be the equivalent on Windows is unnecessarily complex and error prone, and assumes that the variant systems are confi

Re: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink upstream

On 3/8/2011 10:27 PM, Mark Hammond wrote: On 9/03/2011 5:05 PM, Glenn Linderman wrote: Standard installation paths are accepted by about 99% of the users, so embedding standard installation paths can work well for that batch of users. Of course, Windows changes the standard path periodically

Re: [Python-Dev] VM and Language summit info for those not at Pycon (and those that are!)

On 3/12/2011 10:42 AM, Allison Randal wrote: I might convert it directly into a Q&A blog post. I'd like to see that, or a summary, posted here. As a Perl-to-Python convertee, I'm curious about the problematic semantic differences. ___ Python-Dev mai

Re: [Python-Dev] Python3 regret about deleting list.sort(cmp=...)

On 3/12/2011 1:55 PM, Fredrik Johansson wrote: Consider sorting a list of pairs representing fractions. This can be done easily in Python 2.x with the comparison function lambda (p,q),(r,s): cmp(p*s, q*r). In Python 2.6, this is about 40 times faster than using fractions.Fraction as a key functio

Re: [Python-Dev] VM and Language summit info for those not at Pycon (and those that are!)

On 3/12/2011 3:43 AM, Nick Coghlan wrote: I posted my rough notes and additional write-ups for Wednesday's VM summit and Thursday's language summit: http://www.boredomandlaziness.org/2011/03/python-vm-summit-rough-notes.html 2.7 to 3.2 - treat PyPy Python 3 dialect like a major Python libra

Re: [Python-Dev] Python3 regret about deleting list.sort(cmp=...)

On 3/12/2011 2:09 PM, Terry Reedy wrote: I believe that if the integer field were padded with leading blanks as needed so that all are the same length, then no key would be needed. Did you mean that "if the integer field were" converted to string and "padded with leading blanks..."? Otherwi

Re: [Python-Dev] Python3 regret about deleting list.sort(cmp=...)

On 3/12/2011 7:21 PM, Terry Reedy wrote: (Ok, I assumed that the 'word' field does not include any of !"#$%&'()*+. If that is not true, replace comma with space or even a control char such as '\a' which even precedes \t and \n.) OK, I agree the above was your worst assumption, although you nee

Re: [Python-Dev] Draft PEP and reference implementation of a Python launcher for Windows

Not all of the ideas below are complementary to each other, some are either or, to allow different thoughts to be inspired or different directions to be taken. Thanks for starting a PEP. On 3/18/2011 11:02 PM, Mark Hammond wrote: The launcher should be as simple as possible (but no simp

Re: [Python-Dev] Draft PEP and reference implementation of a Python launcher for Windows

ter/* [arg]". ... the interpreter must be a valid pathname for an executable which is not itself a script, which will be invoked as *interpreter* [arg] /filename/. A maximum line length of 127 characters is allowed for the first line in a #! executable shell script. More below in c

Re: [Python-Dev] Hg: inter-branch workflow

On 3/22/2011 2:43 PM, Éric Araujo wrote: Bazaar apparently has a notion of mainline whereas Mercurial believes that all changesets are created equal. The tools are different. I'm curious: what are the benefits of the Mercurial model? Simplicity. That's an amusing response, after reading hund

Re: [Python-Dev] Proposal for Python 3.3: dependence injection

On 3/24/2011 4:25 PM, Nick Coghlan wrote: As an example of the last point, perhaps rather than modifying all the *clients* of the socket module, it may make more sense to have tools in the socket module itself to temporarily customise the socket creation process in the current thread. The advant

Re: [Python-Dev] Python Core Mentorship program

On 3/25/2011 5:44 PM, Laura Creighton wrote: The other side of the proposed forum is people who want to teach such people. Many of them (and no doubt many of the learners) don't read python-list due to its high volume. Indeed. I see 76000+ unread messages on Python-list since I subscribed 2.

Re: [Python-Dev] Python Core Mentorship program

So... start two mentoring groups, one open, one closed, and see which one survives. ___ 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/arch

Re: [Python-Dev] Security implications of pep 383

On 3/29/2011 12:10 PM, Toshio Kuratomi wrote: The possible flaw in python is this: Code like the blog poster wrote passes python3 without an error or a warning. This gives the programmer no feedback that they're doing something wrong until it actually bites them in the foot in deployed code.

Re: [Python-Dev] Please revert autofolding of tracker edit form

On 3/31/2011 9:52 AM, Terry Reedy wrote: I would like to try putting the comment box after the last (most recent) comment, as that is the message one most ofter responds to. Having to now scroll up and down between comment box and last message(s) is often of a nuisance. +1. Or +0 reverse t

Re: [Python-Dev] Please revert autofolding of tracker edit form

On 3/31/2011 5:22 PM, Raymond Hettinger wrote: Perhaps the most important part is that the comment box goes at the top. As long as it is adjacent to the last comment, that would be fine. (said while tongue removing the last bit of supper from the space outside the teeth)

Re: [Python-Dev] Impaired Usability of the Mercurial Source Viewer

On 3/31/2011 8:44 PM, Antoine Pitrou wrote: Impacting only the source viewer looks like it would require a patch to the generation logic, although I could be mistaken. Is there not something in the context surrounding the changelog and the source viewer that is different? And therefore someth

Re: [Python-Dev] Please revert autofolding of tracker edit form

On 4/1/2011 9:08 AM, Terry Reedy wrote: I envy all of you who only have to learn and use one relatively sensible unit system. Me too. But anyone that calls themselves a programmer should be able to realize that the numbers are proportional and Google happily finds online conversion calcul

Re: [Python-Dev] PEP 396, Module Version Numbers

On 4/5/2011 11:52 AM, Barry Warsaw wrote: #. Module version numbers SHOULD conform to the normalized version format specified in PEP 386 [6]_. From PEP 386: Roadmap Distutils will deprecate its existing versions class in favor of Normali

Re: [Python-Dev] PEP 396, Module Version Numbers

On 4/6/2011 7:26 AM, Nick Coghlan wrote: On Wed, Apr 6, 2011 at 6:22 AM, Glenn Linderman wrote: With more standardization of versions, should the version module be promoted to stdlib directly? When Tarek lands "packaging" (i.e. what distutils2 becomes in the Python 3.3 st

Re: [Python-Dev] PEP 396, Module Version Numbers

On 4/6/2011 9:08 PM, Nick Coghlan wrote: On Thu, Apr 7, 2011 at 7:58 AM, Glenn Linderman wrote: Perhaps a different technique would be that if packaging is in use, that it could somehow inject the version from setup.cfg into the module, either by tweaking the source as it gets packaged, or

Re: [Python-Dev] PEP 396, Module Version Numbers

On 4/6/2011 11:53 PM, Nick Coghlan wrote: On Thu, Apr 7, 2011 at 2:55 PM, Glenn Linderman wrote: __version__ = "7.9.7" # replaced by "packaging" If you don't upload your module to PyPI, then you can do whatever you want with your versioning info. If you *do* upl

Re: [Python-Dev] PEP 396, Module Version Numbers

On 4/9/2011 9:23 AM, Éric Araujo wrote: Hi, Le 06/04/2011 23:58, Glenn Linderman a écrit : On 4/6/2011 7:26 AM, Nick Coghlan wrote: On Wed, Apr 6, 2011 at 6:22 AM, Glenn Linderman wrote: With more standardization of versions, should the version module be promoted to stdlib directly? When

Re: [Python-Dev] PyObject_RichCompareBool identity shortcut

On 4/27/2011 8:31 AM, Nick Coghlan wrote: What that means is that "correct" implementations of methods like __contains__, __eq__, __ne__, index() and count() on containers should be using "x is y or x == y" to enforce reflexivity, but most such code does not (e.g. our own collections.abc.Sequence

Re: [Python-Dev] PyObject_RichCompareBool identity shortcut

On 4/27/2011 2:15 PM, Mark Dickinson wrote: On Wed, Apr 27, 2011 at 7:41 PM, Glenn Linderman wrote: One issue that I don't fully understand: I know there is only one instance of None in Python, but I'm not sure where to discover whether there is only a single, or whether there can b

Re: [Python-Dev] PyObject_RichCompareBool identity shortcut

On 4/27/2011 2:04 PM, Mark Dickinson wrote: On Wed, Apr 27, 2011 at 10:37 AM, Hrvoje Niksic wrote: The other day I was surprised to learn this: nan = float('nan') nan == nan False [nan] == [nan] True # also True in tuples, dicts, etc. That one surprises me a bit too: I k

Re: [Python-Dev] PyObject_RichCompareBool identity shortcut

On 4/27/2011 5:05 PM, Steven D'Aprano wrote: (2) slow containers down by guaranteeing that they will use __eq__; (but how much will it actually hurt performance for real-world cases? and this will have the side-effect that non-reflexivity will propagate to containers) I think it is perfect

Re: [Python-Dev] PyObject_RichCompareBool identity shortcut

On 4/27/2011 6:11 PM, Ethan Furman wrote: Mark Dickinson wrote: On Wed, Apr 27, 2011 at 10:37 AM, Hrvoje Niksic wrote: The other day I was surprised to learn this: nan = float('nan') nan == nan False [nan] == [nan] True # also True in tuples, dicts, etc. That one surpri

Re: [Python-Dev] PyObject_RichCompareBool identity shortcut

On 4/27/2011 6:15 PM, Glenn Linderman wrote: I think it is perfectly reasonable that containers containing items with non-reflexive equality should sometimes have non-reflexive equality also (depends on the placement of the item in the container, and the values of other items, whether the non

Re: [Python-Dev] PyObject_RichCompareBool identity shortcut

On 4/27/2011 7:31 PM, Stephen J. Turnbull wrote: Glenn Linderman writes: > I would not, however expect the original case that was described: > >>> nan = float('nan') > >>> nan == nan > False > >>> [nan] == [nan] >

Re: [Python-Dev] PyObject_RichCompareBool identity shortcut

On 4/27/2011 8:06 PM, Stephen J. Turnbull wrote: Glenn Linderman writes: > On 4/27/2011 6:11 PM, Ethan Furman wrote: > > Totally out of my depth, but what if the a NaN object was allowed to > > compare equal to itself, but different NaN objects still compared > &

Re: [Python-Dev] PyObject_RichCompareBool identity shortcut

On 4/27/2011 8:43 PM, Nick Coghlan wrote: On Thu, Apr 28, 2011 at 12:42 PM, Stephen J. Turnbull wrote: Mark Dickinson writes: > Declaring that 'nan == nan' should be True seems attractive in > theory, No, it's intuitively attractive, but that's because humans like nice continuous behav

Re: [Python-Dev] PyObject_RichCompareBool identity shortcut

On 4/27/2011 11:54 PM, Nick Coghlan wrote: On Thu, Apr 28, 2011 at 4:20 PM, Glenn Linderman wrote: In that bug, Nick, you mention that reflexive equality is something that container classes rely on in their implementation. Such reliance seems to me to be a bug, or an inappropriate

Re: [Python-Dev] PyObject_RichCompareBool identity shortcut

On 4/28/2011 12:32 AM, Nick Coghlan wrote: On Thu, Apr 28, 2011 at 5:27 PM, Glenn Linderman wrote: Without having read the original articulations by Raymond or any discussions of the pros and cons, In my first post to this thread, I pointed out the bug tracker item (http://bugs.python.org

Re: [Python-Dev] PyObject_RichCompareBool identity shortcut

On 4/28/2011 4:40 PM, Nick Coghlan wrote: Hmm, true. And things like count() and index() would still be thoroughly broken for sequences. OK, so scratch that idea - there's simply no sane way to handle such objects without using an identity-based container that ignores equality definitions altoget

Re: [Python-Dev] Python 3.x and bytes

On 5/17/2011 10:39 PM, Greg Ewing wrote: Personally I think that the default literal syntax for bytes, and also the form produced by repr(), should have been something more neutral, such as hex, with the ascii form available for use when it makes sense. Much nicer would be some_var = x'dea

Re: [Python-Dev] [Python-checkins] peps: Add rules for indenting continuation lines.

On 6/2/2011 11:19 AM, Barry Warsaw wrote: On Jun 02, 2011, at 08:09 PM, guido.van.rossum wrote: +Continuation lines should align wrapped elements either vertically using +Python's implicit line joining inside parentheses, brackets and braces, +or using a hanging indent of double you

Re: [Python-Dev] [Python-checkins] peps: Add rules for indenting continuation lines.

On 6/2/2011 12:01 PM, Guido van Rossum wrote: Bingo. That's why. (Though you are missing some colons in your examples.:-) --Guido You operate as a good Python compiler :) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailma

Re: [Python-Dev] [Python-checkins] peps: Add rules for indenting continuation lines.

On 6/2/2011 3:49 PM, Guido van Rossum wrote: Except that the rule gets more complicated. I don't think that always using the double indent is going to mean a lot more line breaks, so I don't think there's much benefit to the added complication. Further, tools like python-mode would have to go b

Re: [Python-Dev] [Python-checkins] peps: Add rules for indenting continuation lines.

On 6/2/2011 3:18 PM, Greg Ewing wrote: i.e. indent the *body* one more place. This avoids the jarriness of seeing an outdent that doesn't correspond to the closing of a suite. -1. There are likely many more lines in the suite than in the conditional, that, by being double indented, would now

Re: [Python-Dev] EuroPython Language Summit report

On 6/24/2011 1:30 PM, Terry Reedy wrote: The third is to make utf-8 the default. I believe this *is* the proper long term solution and both options are contrary to this. +1 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/ma

[Python-Dev] 3.2.1 encoding surprise

Attached reduced test case works fine with Python 3.1, fails with Python3.2: SyntaxError: Non-ASCII character '\xc3' in file D:\my\py\t32enc.py on line 1, but no encoding declared; see http://www.python.org/peps/pep-0263.html for details I'm familiar with the PEP, but thought 3.x cured that.

Re: [Python-Dev] 3.2.1 encoding surprise

On 7/18/2011 1:01 PM, Paul Moore wrote: 2011/7/18 Glenn Linderman: Attached reduced test case works fine with Python 3.1, fails with Python3.2: PS D:\Data> py -3 .\t32enc.py PS D:\Data> py -2 .\t32enc.py File ".\t32enc.py", line 1 SyntaxError: Non-ASCII characte

Re: [Python-Dev] 3.2.1 encoding surprise

On 7/18/2011 2:13 PM, Vinay Sajip wrote: Remember that there are two sets of locations - HKCU and HKLM - where the type associations are potentially held. Please do a registry search (with Administrator rights so you can search the whole registry) for "py.exe" or "pyw.exe" and see if they show up

Re: [Python-Dev] 3.2.1 encoding surprise

On 7/18/2011 2:13 PM, Vinay Sajip wrote: The reason I thought it did nothing, is that I checked assoc ( =Python.File ) and ftype ( =c:\python32\python.exe "%1" %* ) both of which look familiar, and neither of which mention py.exe which is what I think the launcher is suppo

Re: [Python-Dev] 3.2.1 encoding surprise

On 7/18/2011 4:55 PM, Vinay Sajip wrote: Glenn Linderman g.nevcal.com> writes: Here is a list of py.exe references in my registry: HCR\Python.CompiledFile HCR\Python.File HCR\Python.NoConFile [snip] There shouldn't be so many references, so I suggest

Re: [Python-Dev] 3.2.1 encoding surprise

On 7/18/2011 6:41 PM, Vinay Sajip wrote: Yes, but the launcher installer is beta software, and it's not yet clear exactly how the launcher will be packaged with Python 3.3. Clearly if packaged as an automatic installation with Python, it will use Python defaults. Sure, and that's why I'm trying

Re: [Python-Dev] 3.2.1 encoding surprise

On 7/18/2011 7:03 PM, Glenn Linderman wrote: Wonder if there is a third party command line tool which augments them for reading/setting HCU Classes? Will search. I know there is a command line registry tool somewhere, but specifying the paths correctly would be onerous. XP+ has REG and

Re: [Python-Dev] Draft PEP: "Simplified Package Layout and Partitioning"

On 7/19/2011 8:58 PM, P.J. Eby wrote: Standard Library Changes/Additions -- The ``pkgutil`` module should be updated to handle this specification appropriately, including any necessary changes to ``extend_path()``, ``iter_modules()``, etc. Specifically the propos

Re: [Python-Dev] 3.2.1 encoding surprise

On 7/18/2011 6:41 PM, Vinay Sajip wrote: > So I can fix my machine, now that I understand what went wrong > (delete py.exe entries from HCU, and put them in HLM instead). > Then the other problem I have, is why py.exe launched py 2.6.4 > instead of py 3.2.1 when 3.2.1 is ne

Re: [Python-Dev] 3.2.1 encoding surprise

On 7/20/2011 7:19 AM, Vinay Sajip wrote: Glenn Linderman g.nevcal.com> writes: Since I don't yet have associations set up that point at the launcher, I thought I'd play with saying "py" in front of the command. Why don't you have any associati

Re: [Python-Dev] Draft PEP: "Simplified Package Layout and Partitioning"

On 7/20/2011 6:05 AM, P.J. Eby wrote: At 02:24 AM 7/20/2011 -0700, Glenn Linderman wrote: When I read about creating __path__ from sys.path, I immediately thought of the issue of programs that extend sys.path, and the above is the "workaround" for such programs. but it req

Re: [Python-Dev] Draft PEP: "Simplified Package Layout and Partitioning"

On 7/20/2011 4:03 PM, P.J. Eby wrote: I'd recommend *always* using it, outside of simple startup code. So that is a burden on every program. Documentation would help, but it certainly makes updating sys.path much more complex -- 3 lines (counting import of pkgutil) instead of one, and the co

Re: [Python-Dev] 3.2.1 encoding surprise

On 7/20/2011 4:41 PM, Mark Hammond wrote: On 21/07/2011 7:43 AM, Glenn Linderman wrote: ... I still get the same behavior. Is there any debugging output produced by py.exe that would tell what py.ini it looks in, and what the content is? What diagnostic steps might I take to produce

Re: [Python-Dev] 3.2.1 encoding surprise

On 7/20/2011 2:43 PM, Glenn Linderman wrote: It's not py's job to walk the path: the shell does that when you just type "foo". It locates foo.py, and then invokes py because of file association - py then checks the file for a shebang to decide which Python to dispatch it to.

Re: [Python-Dev] 3.2.1 encoding surprise

On 7/20/2011 5:07 PM, Nick Coghlan wrote: On Thu, Jul 21, 2011 at 8:51 AM, Ethan Furman wrote: I would say that would be a cool enhancement, as it could save a bit of typing, but I think the launcher is quite useful even without path traversal. Two related points: 1. Walking PATH isn't necess

Re: [Python-Dev] 3.2.1 encoding surprise

On 7/20/2011 5:11 PM, Mark Hammond wrote: On 21/07/2011 10:02 AM, Glenn Linderman wrote: So this tells me that it didn't find a local py.ini (no surprise, I don't have one) but doesn't tell me that it did find or read c:\Windows\system32\py.ini much less whether I have the syntax

Re: [Python-Dev] 3.2.1 encoding surprise

On 7/20/2011 8:22 PM, Nick Coghlan wrote: On Thu, Jul 21, 2011 at 12:52 PM, R. David Murray wrote: Indeed. If I want to run a script with a different python version on a unix-like system, I need to know the path to said script. We're trying to make python as easy to use on Windows as it is on

Re: [Python-Dev] 3.2.1 encoding surprise

On 7/20/2011 5:34 PM, Mark Hammond wrote: On 21/07/2011 10:13 AM, Glenn Linderman wrote: On 7/20/2011 2:43 PM, Glenn Linderman wrote: It's not py's job to walk the path: the shell does that when you just type "foo". It locates foo.py, and then invokes py because of file a

Re: [Python-Dev] New update to PEP397 - Python launcher for Windows

On 7/20/2011 11:35 PM, Mark Hammond wrote: * If the command starts with the definition of a customized command followed by a space character, the customized command will be used. See below for a description of customized commands. Then a shebang line of '#! vpython' in

Re: [Python-Dev] 3.2.1 encoding surprise

On 7/21/2011 8:20 AM, Michael Foord wrote: On 21/07/2011 15:43, Paul Moore wrote: On 21 July 2011 09:13, Glenn Linderman wrote: Certainly when the launcher is invoked via an association, this would be the case. However, when the launcher is invoked via the command line, then the unqualified

Re: [Python-Dev] 3.2.1 encoding surprise

On 7/20/2011 5:11 PM, Mark Hammond wrote: It may be that your copy of the launcher is a little old - some changes were pushed just yesterday (but I'm not sure if Vinay made a new installer yet). It has slightly better debug output (although generally not what you are asking for yet) and better

Re: [Python-Dev] New update to PEP397 - Python launcher for Windows

On 7/20/2011 11:35 PM, Mark Hammond wrote: Customized Commands: The launcher will support the ability to define "Customized Commands" in a Windows .ini file (ie, a file which can be parsed by the Windows function GetPrivateProfileString). A section called '[commands]' can be crea

Re: [Python-Dev] New update to PEP397 - Python launcher for Windows

On 7/20/2011 11:35 PM, Mark Hammond wrote: Virtual commands in shebang lines: Virtual Commands are shebang lines which start with strings which would be expected to work on Unix platforms - examples include '/usr/bin/python', '/usr/bin/env python' and 'python'. Optionally, the

<    1   2   3   4   5   6   7   >