Re: [Python-Dev] == on object tests identity in 3.x
On 2014-07-07, at 13:22 , Andreas Maier wrote:
> While discussing Python issue #12067
> (http://bugs.python.org/issue12067#msg222442), I learned that Python 3.4
> implements '==' and '!=' on the object type such that if no special equality
> test operations are implemented in derived classes, there is a default
> implementation that tests for identity (as opposed to equality of the values).
>
> The relevant code is in function do_richcompare() in Objects/object.c.
>
> IMHO, that default implementation contradicts the definition that '==' and
> '!=' test for equality of the values of an object.
>
> Python 2.x does not seem to have such a default implementation; == and !=
> raise an exception if attempted on objects that don't implement equality in
> derived classes.
That's incorrect on two levels:
1. What Terry notes in the bug comments is that because all Python 3
types inherit from object this can be done as a default __eq__/__ne__,
in Python 2 the fallback is encoded in the comparison framework
(PyObject_Compare and friends):
http://hg.python.org/cpython/file/01ec8bb7187f/Objects/object.c#l756
2. Unless comparison methods are overloaded and throw an error it will
always return either True or False (for comparison operator), never throw.
> I'd like to gather comments on this issue, specifically:
>
> -> Can someone please elaborate what the reason for that is?
>
> -> Where is the discrepancy between the documentation of == and its default
> implementation on object documented?
>
> To me, a sensible default implementation for == on object would be (in
> Python):
>
> if v is w:
>return True;
> elif type(v) != type(w):
>return False
> else:
>raise ValueError("Equality cannot be determined in default implementation")
Why would comparing two objects of different types return False but
comparing two objects of the same type raise an error?
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Critical bash vulnerability CVE-2014-6271 may affect Python on *n*x and OSX
On 2014-09-27, at 00:11 , Cameron Simpson wrote: > On 26Sep2014 13:16, Antoine Pitrou wrote: >> On Fri, 26 Sep 2014 01:10:53 -0700 >> Hasan Diwan wrote: >>> On 26 September 2014 00:28, Matěj Cepl wrote: >>> > Where does your faith that other /bin/sh implementations (dash, >>> > busybox, etc.) are less buggy comes from? >>> >>> The fact that they are simpler, in terms of lines of code. It's no >>> guarantee, but the less a given piece of code does, the less bugs it will >>> have. -- H >> >> And that they have less "features" (which is certainly correlated to >> their simplicity). IIUC, the misimplemented feature leading to this >> vulnerability is a bash-ism. > > IIRC you could export functions in ksh. Or maybe only aliases. But that > implies most POSIX shells may support it. From my understanding KSH's function export is so a function becomes available in the caller of a script e.g. if you define a function in your .kshrc it's internal to the file (and won't be available in the interactive shell) unless you export it: http://users.speakeasy.net/~arkay/216-7.4KshFunctions.html KSH (and ZSH) will also load functions from files on $FPATH, but AFAIK that's it. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Improvements for Pathlib
On 2014-11-08, at 16:46 , Ionel Cristian Mărieș wrote: > Hello, > > In the current incarnation Pathlib is missing some key features I need in my > usecases. I want to contribute them but i'd like a bit of feedback on the new > api before jumping to implementation. > > The four things I need are: > > #1. A context manager for temporary files and dirs (that cleans everything up > on exit). Eg: > > with pathlib.TmpDir(suffix='', prefix='') as tmp: > assert isinstance(tmp, pathlib.Path) > > with pathlib.TmpFile(suffix='', prefix='') as tmp: > assert isinstance(tmp, pathlib.Path) > Why would pathlib need to provide this when tempfile already does? with tempfile.NamedTemporaryFile(prefix='') as f: tmp = pathlib.Path(f.name) with tempfile.TemporaryDirectoryDirectory(prefix='') as d: tmp = pathlib.Path(d.name) On 2014-11-08, at 19:14 , Ryan Gonzalez wrote: > +1 for the context manager ideas. Anything that is like a resource should be > available as a context manager. The current working directory is not "a resource" though it's a big piece of global state. I've been bitten by context-manager-unexpectedly-being-global-state in the past (with warnings.catch_warnings, I had not noticed the note about thread-safety). All in all, not a fan. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Improvements for Pathlib
On 2014-11-08, at 20:02 , Ionel Cristian Mărieș wrote: > On Saturday, November 8, 2014, Xavier Morel wrote: > > Why would pathlib need to provide this when tempfile already does? > > with tempfile.NamedTemporaryFile(prefix='') as f: > tmp = pathlib.Path(f.name) > > with tempfile.TemporaryDirectoryDirectory(prefix='') as d: > tmp = pathlib.Path(d.name) > > For the same reason pathlib provides path manipulation functionality while > os.path already does: a cohesive and more convenient api. In other words, I > want to have less calls and variables around (less room for errors, less > visual bloat), and this is such a common pattern it's worth supporting it in > pathlib. But now you've got two different places for tempfiles depending whether you want them to have an fs path or not. And the API isn't even more convenient when it comes to tempfiles, only to tempdir. Which could be fixed just as easily by adding a `path` attribute to tempfile.TemporaryDirectory. On 2014-11-08, at 21:41 , Ethan Furman wrote: > On 11/08/2014 10:46 AM, Xavier Morel wrote: >> On 2014-11-08, at 16:46 , Ionel Cristian Mărieș wrote: >>> >>> In the current incarnation Pathlib is missing some key features I need in >>> my usecases. I want to contribute them but i'd like a bit of feedback on >>> the new api before jumping to implementation. > >>> #1. A context manager for temporary files and dirs (that cleans everything >>> up on exit). >> >> Why would pathlib need to provide this when tempfile already does? > > Because tempfile doesn't accept PathLib instances? Which can be fixed by adding support for `dir` being a Path in mkstemp, mktemp and mkdtemp. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] How far to go with user-friendliness
On 2015-07-14, at 14:39 , Nick Coghlan wrote: > On 14 July 2015 at 22:06, Dima Tisnek wrote: >> Thus the question, how far should Python go to detect possible >> erroneous user behaviour? >> >> Granted it is in tests only, but why not detect assrte, sasert, saster >> and assrat? > > Because "r" and "e" are right next to each other on a QWERTY keyboard > (so it's an easy typo to make), and transposing them doesn't change > the overall shape of the word (so it's a hard typo to detect). > If you get the "a" or "t" out of position you change the shape of the > word so typos involving those are easier to detect visually, while "s" > and "e" are on different keyboard rows so typos at that point in the > word are less likely in the first place. "sasert" fits these rules though. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [python-committers] How are we merging forward from the Bitbucket 3.5 repo?
On 2015-08-16, at 16:08 , Guido van Rossum wrote: > I presume the issue here is that Hg is so complicated that everyone knows a > different subset of the commands and semantics. > > I personally don't know what the commands for cherry-picking a revision would > be. graft > I also don't know exactly what happens when you merge a PR using bitbucket. > (I'm only familiar with the GitHub PR flow, and I don't like its behavior, > which seems to always create an extra merge revision for what I consider as > logically a single commit.) Same thing IIRC, I don't think there's a way to "squash" a merge via the web interface in either. > BTW When I go to https://bitbucket.org/larry/cpython350 the first thing I see > (in a very big bold font) is "This is Python version 3.6.0 alpha 1". What's > going on here? It doesn't inspire confidence. It's the rendered content of the README file at the root of the repository, same as github.___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Context management patterns
On 2013-10-19, at 08:38 , Nick Coghlan wrote:
>> The above example, especially if extended beyond two files, begs to used in
>> a loop, like your 5 line version:
>>
>>
>> for name in ("somefile.tmp", "someotherfile.tmp"):
>> with suppress(FileNotFoundError):
>>os.remove(name)
>>
>> which would be fine, of course.
>>
>> But to some with less education about the how and why, it is not clear why
>> it couldn't be written like:
>>
>> with suppress(FileNotFoundError):
>>
>>for name in ("somefile.tmp", "someotherfile.tmp"):
>>os.remove(name)
>>
>> yet to the cognoscenti, it is obvious there are seriously different
>> semantics.
>
> However, that's a confusion about exception handling in general, not
> about the suppress context manager in particular. The same potential
> for conceptual confusion exists between:
>
>for name in ("somefile.tmp", "someotherfile.tmp"):
>try:
>os.remove(name)
>except FileNotFoundError:
>pass
>
> and:
>
>try:
>for name in ("somefile.tmp", "someotherfile.tmp"):
> os.remove(name)
>except FileNotFoundError:
>pass
It could work if the exceptions system was extended to a full-blow
conditions system though.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 428 - pathlib - ready for approval
On 2013-11-20, at 17:09 , Guido van Rossum wrote: > On Wed, Nov 20, 2013 at 6:01 AM, Ethan Furman wrote: > On 11/20/2013 04:25 AM, Garth Bushell wrote: > > I'm also quite uneasy on the case insensitive comparison on Windows as the > File system NTFS is case sensitive. > > No, it's case-preserving. > > It's quite possible that you are both right -- possibly the filesystem driver > supports foo and FOO in the same directory but the kernel I/O layer prohibits > that. Stranger things have happened. (IIRC the behaviour might have been > intended so that NT could get a "POSIX compliant" stamp of approval -- using > a different set of kernel interfaces that don't enforce case insensitive > matching.) The Subsystem for Unix-based Applications (SUA, formerly WSU and née Interix) does expose NTFS’s case sensitivity, but FWIW it was originally developed outside of Microsoft and independently from NTFS (and a few years later). It looks like NTFS’s designers simply didn’t feel completely beholden to the limitations of the Windows API. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bug? http.client assumes iso-8859-1 encoding of HTTP headers
On 2014-01-04, at 17:24 , Chris Angelico wrote:
> On Sun, Jan 5, 2014 at 2:36 AM, Hugo G. Fierro wrote:
>> I am trying to download an HTML document. I get an HTTP 301 (Moved
>> Permanently) with a UTF-8 encoded Location header and http.client decodes it
>> as iso-8859-1. When there's a non-ASCII character in the redirect URL then I
>> can't download the document.
>>
>> In client.py def parse_headers() I see the call to decode('iso-8859-1'). My
>> personal hack is to use whatever charset is defined in the Content-Type
>> HTTP header (utf8) or fall back into iso-8859-1.
>>
>> At this point I am not sure where/how a fix should occur so I thought I'd
>> run it by you in case I should file a bug. Note that I don't use http.client
>> directly, but through the python-requests library.
>
> I'm not 100% sure, but I believe non-ASCII characters are outright
> forbidden in a Location: header. It's possible that an RFC2047 tag
> might be used, but my reading of RFC2616 is that that's only for text
> fields, not for Location. These non-ASCII characters ought to be
> percent-encoded, and anything doing otherwise is buggy.
That is also my reading, the Location field’s value is defined as an
absoluteURI (RFC2616, section 14.30):
> Location = "Location" ":" absoluteURI
section 3.2.1 indicates that "absoluteURI" (and other related
concepts) are used as defined by RFC 2396 "Uniform Resource
Identifiers (URI): Generic Syntax", that is:
> absoluteURI = scheme ":" ( hier_part | opaque_part )
both "hier_part" and "opaque_part" consist of some punctuation
characters, "escaped" and "unreserved". "escaped" is %-encoded
characters which leaves "unreserved" defined as "alphanum | mark".
"mark" is more punctuation and "alphanum" is ASCII's alphanumeric
ranges.
Furthermore, although RFC 3986 moves some stuff around and renames some
production rules, it seems to have kept this limitation.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5
On 2014-01-06, at 14:44 , Antoine Pitrou wrote:
>> Then,
>> the following points must be decided to define the complete list of
>> supported features (formatters):
>>
>> * Format integer to hexadecimal? ``%x`` and ``%X``
>> * Format integer to octal? ``%o``
>> * Format integer to binary? ``{!b}``
>> * Alignment?
>> * Truncating? Truncate or raise an error?
>
> Not desirable IMHO. bytes formatting should serve mainly for templating
> situations (i.e. catenate and insert bytestrings into one another). We
> cannot start giving text-like semantics to bytes objects without
> confusing non-experts.
But having at least some of struct's formatting options available on
bytes.format or bytes % would be useful.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reference cycles in Exception.__traceback__
On 2014-03-06, at 16:52 , Antoine Pitrou wrote: > Le 06/03/2014 16:03, Yury Selivanov a écrit : >> >> On 2014-03-06, 8:42 AM, Antoine Pitrou wrote: >>> Le 05/03/2014 23:53, Nick Coghlan a écrit : __traceback__ wouldn't change [...] >>> >>> Uh, really? If you want to suppress all reference cycles, you *have* >>> to remove __traceback__. >>> >>> The problem is to make computation of the traceback summary >>> lightweight enough that it doesn't degrade performance in the common >>> case where you don't have to print the traceback later. >> >> So why can't we allow instantiation of types.TracebackType & >> types.FrameType? > > IMO it is absolutely out of question to allow creation of arbitrary frames > from Python code, because the structure and initialization of frames embody > too many low-level implementation details. > > We might allow the creation of traceback objects, but without any custom > frame objects it is unclear how useful that would be. Some bits of the standard library (and probably third-party libraries transitively relying on getinnerframes) really, really want traceback objects and can't be used with a stack or frames extracted via inspect.currentframe() or whatever. For instance cgitb.text calls inspect.getinnerframes which accesses param.tb_frame then calls getframeinfo(param). getframeinfo blows up if it does not get either an actual traceback object or an actual frame object. A frame object does not have a tb_frame attribute, and will thus fail in getinnerframes, a fake traceback object will fail in getframeinfo. Therefore it's not possible to call cgitb.text outside of an exception handling context (that is, not possible to use it as a traceback.print_stack providing extra information). If it were possible to create traceback objects, there would be no issue there at least. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reference cycles in Exception.__traceback__
On 2014-03-06, at 19:32 , Guido van Rossum wrote: > But inspect is in the stdlib. Surely changing inspect.py is less > controversial than amending the semantics of frame objects. I've no idea, I'm just giving a case where I could have used the ability to create traceback objects even without the ability to create stack frames (changing the stdlib may also be an option, though I'd hope the explicit type checks were put in there for a reason) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Negative timedelta strings
On 2014-03-28, at 17:19 , Skip Montanaro wrote: > (*) As an aside (that is, this belongs in a separate thread if you > want to discuss it), in my opinion, attempting to support ISO 8601 > formatting is pointless without the presence of an anchor datetime. > Otherwise how would you know how far back "five months" or "seven > years" was? dateutil's relativedelta keeps the notion "abstract" until it's combined with an anchor datetime, at which point it's reified to a real duration[0]. > If that's the case, then you might as well add the timedelta to your anchor datetime and just use datetime.strftime(). You can't even express "next month" with timedelta, since the duration of a month is not a fixed number of seconds. [0] well not exactly, a relativedelta really defines a processing pipeline on its anchor date, which allows for fun stuff like "saturday the third week of next month". ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Negative timedelta strings
On 2014-04-02, at 15:04 , Skip Montanaro wrote: > On Wed, Apr 2, 2014 at 7:52 AM, M.-A. Lemburg wrote: > print now() + RelativeDateTime(months=+1, day=1) >> 2014-05-01 14:49:05.83 > > I find this sort date arithmetic unintuitive, though I'm at a loss to > come up with better logic than you have: > d = Date(2014, 2, 28) d + RelativeDateTime(months=+1) > d = Date(2014, 1, 31) d + RelativeDateTime(months=+1) > > > I guess the assumption is that one month is the length in days of the > current month, though, you wind up with situations where shorter > months can be skipped altogether. Is there a way to talk in terms of > "months" but not have short months get skipped? FWIW dateutil has a slightly different logic there: >>> date(2014, 2, 28) + relativedelta(months=+1) datetime.date(2014, 3, 28) >>> date(2014, 1, 31) + relativedelta(months=+1) datetime.date(2014, 2, 28) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compact ordered set
> On 2019-02-28, at 12:56 , Antoine Pitrou wrote: > > On Thu, 28 Feb 2019 22:43:04 +1100 > Steven D'Aprano wrote: >> On Wed, Feb 27, 2019 at 02:15:53PM -0800, Barry Warsaw wrote: >> >>> I’m just relaying a data point. Some Python folks I’ve worked with do >>> make the connection between dicts and sets, and have questions about >>> the ordering guarantees of then (and how they relate). >> >> Sets and dicts are not related by inheritence (except that they're both >> subclasses of ``object``, but so is everything else). They don't share >> an implementation. They don't provide the same API. They don't do the >> same thing, except in the most general sense that they are both >> collections. >> >> What connection are these folks making? > > Some of them may be coming from C++, where the respective > characteristics of set and map (or unordered_set and > unordered_multimap) are closely related. I'm sure other languages > show similar analogies. Indeed e.g. Rust's hashset is a trivial wrapper around a hashmap (with no value): https://doc.rust- lang.org/src/std/collections/hash/set.rs.html#121-123, its btreeset has the exact same relationship to btreemap: https://doc.rust- lang.org/src/alloc/collections/btree/set.rs.html#72-74 > On a more abstract level, set and dict are both content-addressed > collections parametered on hash and equality functions. For > algorithmically-minded people it makes sense to see a close connection > between them. I can't speak for anyone else but before seeing this thread I actually assumed (without any evidence or having checked obviously) that the set builtin was built on top of dict or that they were built on the same base and that the changes to dict's implementation in 3.6 (ordering, space, …) had affected sets in the same way. That seems intuitively straightforward, even more so with dict.keys() being a set. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cffi in stdlib
On 2013-02-27, at 14:31 , Antoine Pitrou wrote: > Le Wed, 27 Feb 2013 12:15:05 +1300, > Greg Ewing a écrit : >> Antoine Pitrou wrote: >>> Or we'll go straight to 5. >>> (or switch to date-based numbering :-)) >> >> We could go the Apple route and start naming them after >> species of snake. > > We have to find sufficiently silly species of snakes, though. With about 3000 extant snake species, that should be manageable. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Difference in RE between 3.2 and 3.3 (or Aaron Swartz memorial)
On 2013-03-07, at 11:08 , Matej Cepl wrote: > On 2013-03-06, 18:34 GMT, Victor Stinner wrote: >> In short, Unicode was rewritten in Python 3.3 for the PEP 393. It's >> not surprising that minor details like singleton differ. You should >> not use "is" to compare strings in Python, or your program will fail >> on other Python implementations (like PyPy, IronPython, or Jython) or >> even on a different CPython version. > > I am sorry, I don't understand what you are saying. Even though > this has been changed to > https://github.com/mcepl/html2text/blob/fix_tests/html2text.py#L90 > the tests still fail. > > But, Amaury is right: the function doesn't make much sense. > However, ... > > when I have “fixed it” from > https://github.com/mcepl/html2text/blob/master/html2text.py#L95 > > def onlywhite(line): > """Return true if the line does only consist of whitespace characters.""" > for c in line: > if c is not ' ' and c is not ' ': > return c is ' ' > return line > > to > https://github.com/mcepl/html2text/blob/fix_tests/html2text.py#L90 > > def onlywhite(line): > """Return true if the line does only consist of whitespace > characters.""" > for c in line: >if c != ' ' and c != ' ': > return c == ' ' > return line The second test looks like some kind of corruption, it's supposedly iterating on the characters of a line yet testing for two spaces? Is it possible that the original was a literal tab embedded in the source code (instead of '\t') and that got broken at some point? According to its name + docstring, the implementation of this method should really be replaced by `return line and line.isspace()` (the first part being to handle the case of an empty line: in the current implementation the line will be returned directly if no whitespace is found, which will be "negative" for an empty line, and ''.isspace() -> false). Does that fix the failing tests? ___ 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/archive%40mail-archive.com
Re: [Python-Dev] can't assign to function call
On 2013-03-18, at 15:23 , Chris Angelico wrote: > On Tue, Mar 19, 2013 at 12:50 AM, Neal Becker wrote: >> def F(x): >>return x >> >> x = 2 >> F(x) = 3 >> >>F(x) = 3 >> SyntaxError: can't assign to function call >> >> Do we really need this restriction? There do exist other languages without >> it. > > The languages that permit you to assign to a function call all have > some notion of a reference type. Alternatively they're functional language defining "match cases" e.g. in Haskell a function is defined as foo a b c = someOperation a b c which is functionally equivalent to Python's def foo(a, b, c): return someOperation(a, b, c) ___ 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/archive%40mail-archive.com
Re: [Python-Dev] IDLE in the stdlib
On 2013-03-20, at 20:38 , Barry Warsaw wrote: > On Mar 20, 2013, at 12:31 PM, Guido van Rossum wrote: > >> Agreed that the "sync into stdlib" think should not happen, or should at >> best be a temporary measure until we can remove idle from the source >> tarball (maybe at the 3.4 release, otherwise at 3.5). > > Right. Ultimately, I think IDLE should be a separate project entirely, but I > guess there's push back against that too. The problem with it is, well, that it's a separate project so unless it is still packaged in (in which case it's not quite separate project, just a separate source tree) it's got to be downloaded and installed separately. That would be a blow to educators, but also Windows users: while the CLI works very nicely in unices, that's not the case with the win32 console which is as best as I can describe it a complete turd, making IDLE a very nice proposition there (I never use IDLE on Linux or OSX, but do all the time in Windows). It also provides a rather capable (and in many case sufficient) code editor for a platform which lacks any form of native text editor allowing sane edition of code. Installing the Python windows packages and having everything "work" (in the sense that you can immediately start writing and running python code) is — I think — a pretty big feature. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] IDLE in the stdlib
On 2013-03-20, at 20:59 , Brian Curtin wrote: > On Wed, Mar 20, 2013 at 2:51 PM, Xavier Morel wrote: >> That would be a blow to educators, but also Windows users: while the CLI >> works very nicely in unices, that's not the case with the win32 console >> which is as best as I can describe it a complete turd, making IDLE a >> very nice proposition there (I never use IDLE on Linux or OSX, but do >> all the time in Windows). > > Can you explain this a bit more? I've been using the CLI python.exe on > Windows, Mac, and Linux for years and I don't know what you're talking > about. Windows's terminal emulator (the "win32 console")'s deficiencies don't break it for running existing script, but make using it interactively a rather thankless task, at least as far as I'm concerned: no readline keybinding (e.g. C-a & C-e), very limited scrollback, fixed width, non-handling of signals (C-d will simply print ^D, a syntax error), odd copy behavior (rectangle copies *only*), etc… ___ 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/archive%40mail-archive.com
Re: [Python-Dev] IDLE in the stdlib
On 2013-03-20, at 21:14 , Eli Bendersky wrote: >>> Agreed that the "sync into stdlib" think should not happen, or should at > best be a temporary measure until we can remove idle from the source tarball (maybe at the 3.4 release, otherwise at 3.5). >>> >>> Right. Ultimately, I think IDLE should be a separate project entirely, >> but I >>> guess there's push back against that too. >> >> The problem with it is, well, that it's a separate project so unless it >> is still packaged in (in which case it's not quite separate project, >> just a separate source tree) it's got to be downloaded and installed >> separately. >> >> That would be a blow to educators, but also Windows users: while the CLI >> works very nicely in unices, that's not the case with the win32 console >> which is as best as I can describe it a complete turd, making IDLE a >> very nice proposition there (I never use IDLE on Linux or OSX, but do >> all the time in Windows). It also provides a rather capable (and in many >> case sufficient) code editor for a platform which lacks any form of >> native text editor allowing sane edition of code. >> >> Installing the Python windows packages and having everything "work" (in >> the sense that you can immediately start writing and running python >> code) is — I think — a pretty big feature. > > > Oh, and another thing. If a Windows user wants a good Python shell, IDLE > should be his last choice. There's Spyder, there's IPython, there's > probably a bunch of others I'm not aware of. Sure, there are plenty of tools for the experienced python developer with reasons to invest time in a windows development setup, but IDLE provides an acceptable low-cost and low-investment base which is *there*: it does not require spending a day downloading, trying out and getting familiar with a dozen different Python IDEs, it's simple and for the most part it works. I view it as an mg, not an emacs, if you see what I mean. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Semantics of __int__(), __index__()
On 2013-04-03, at 19:46 , Barry Warsaw wrote:
> On Apr 04, 2013, at 03:04 AM, Steven D'Aprano wrote:
>
>> On 04/04/13 01:16, Barry Warsaw wrote:
>
>>> the other built-in types-as-functions, so int() calls __int__() which must
>>> return a concrete integer.
>
>> Why must it? I think that's the claim which must be justified, not just taken
>> as a given. When we call n = int(something), what's the use-case for caring
>> that n is an instance of built-in int but not of a subclass, and is that
>> use-case so compelling that it must be enforced for all uses of int() etc.?
>
> It's a consistency-of-implementation issue. Where built-in types are
> callable, they return concrete instances of themselves. This is true for
> e.g. list, tuple, dict, bytes, str, and should also be true of int.
FWIW unless I missed something it's true for none of bytes, str or
float, though it's true for complex (for some reason):
types = (int, float, complex, bytes, str)
Obj = type('Obj', (), {
'__{0.__name__}__'.format(t): (lambda t: lambda self:
type('my_{0.__name__}'.format(t), (t,), {})())(t)
for t in types
})
obj = Obj()
for t in types:
print("{} = {} ? {}".format(t, type(t(obj)), type(t(obj)) is t))
> python3 test.py
= ? False
= ? False
= ? True
= ? False
= ? False
bool can not be subclassed so the question doesn't make sense for it
Broadly speaking (complex doesn't fit it), if there's a dedicated dunder
method in the data model, the only check on what it returns is that it's
a subtype of the conversion type. list, tuple and dict use non-dedicated
conversion methods (iteration or a fallback thereof) so they don't have
this occasion and have no choice but to instantiate "themselves"
___
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/archive%40mail-archive.com
Re: [Python-Dev] Semantics of __int__(), __index__()
On 2013-04-04, at 16:47 , Chris Angelico wrote: > Sure, I could override __new__ to do stupid things Or to do perfectly logical and sensible things, such as implementing "cluster classes" or using the base class as a factory of sorts. > in terms of logical expectations, I'd expect > that Foo(x) will return a Foo object, not a Bar object. The problem is the expectation of what "a Foo object" is: type-wise, any Bar object is also a Foo object. I would not expect Foo() to return an object of a completely unrelated type, but returning an object of a subtype? That does not seem outlandish. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Semantics of __int__(), __index__()
On 2013-04-04, at 17:01 , Chris Angelico wrote: > On Fri, Apr 5, 2013 at 1:59 AM, Guido van Rossum wrote: >> On Thu, Apr 4, 2013 at 7:47 AM, Chris Angelico wrote: >>> Is there any argument that I can pass to Foo() to get back a Bar()? >>> Would anyone expect there to be one? Sure, I could override __new__ to >>> do stupid things, but in terms of logical expectations, I'd expect >>> that Foo(x) will return a Foo object, not a Bar object. Why should int >>> be any different? What have I missed here? >> >> >> A class can define a __new__ method that returns a different object. E.g. >> (python 3): >> > > Right, I'm aware it's possible. But who would expect it of a class? Given it's one of the use cases for __new__ and immutable types have to be initialized through __new__ anyway, why would it be unexpected? ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Why can't I encode/decode base64 without importing a module?
On 2013-04-25, at 11:25 , Antoine Pitrou wrote:
>
> Besides, I would consider a RFC more authoritative than a
> Wikipedia definition.
> Base encoding of data is used in many situations to store or transfer
> data in environments that, perhaps for legacy reasons, are restricted
> to US-ASCII [1] data.
so the output is US-ASCII data, a byte stream.
Stephen is correct that you could decide you don't care about those
semantics, and implement base64 encoding as a bytes -> str decoding then
requiring a re-encoding (to ascii) before wire transmission.
The clarity of the interface (or lack thereof) would probably make users
want to send a strongly worded letter to whoever implemented it though,
I don't think `data.decode('base64').encode('ascii')` would fit the
"obviousness" or "readability" expectations of most users.
___
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/archive%40mail-archive.com
Re: [Python-Dev] PEP 435: pickling enums created with the functional API
On 2013-05-07, at 17:03 , Nick Coghlan wrote: > > Specifically, what I'm talking about is some kind of implicit context > similar to the approach the decimal module uses to control operations > on Decimal instances. Wouldn't it be a good occasion to add actual, full-fledged and correctly implemented (and working) dynamically scoped variables? Or extending exceptions to signals (in the Smalltalk/Lisp sense) providing the same feature? ___ 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/archive%40mail-archive.com
Re: [Python-Dev] DTRACE support
On 2013-09-06, at 19:05 , Antoine Pitrou wrote: > On Fri, 06 Sep 2013 18:14:26 +0200 > Jesus Cea wrote: >> >>> Right now, I agree with Charles-François: your patch is too >>> intrusive. >> >> It is intrusive. Yes. I think it must be, by its own nature. Probably >> room for improvement and code transparency. But... are Python-DEVs >> interested in the project?. That is the point :) > > Well, I'm not *personally* interested in anything that only addresses > Solaris, OS X and the like :) For what it's worth, there's also a linux port and oracle's distro has dtrace support. > And, no, it doesn't have to be *that* intrusive. Take a look at Dave > Malcolm's systemtap patch, which IIRC takes a much more sensible > approach. Is there a possibility of compatibility there, using the same placeholders for a --with-dtrace and --with-systemtap build? Jesus seems to instrument more points than Dave, but the extra points could just be defined to nothing in the systemtap implementation. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] DTRACE support
On 2013-09-07, at 05:40 , Jesus Cea wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 06/09/13 20:33, Antoine Pitrou wrote: >> On Fri, 06 Sep 2013 18:14:26 +0200 Jesus Cea wrote: >>> >>> It is intrusive. Yes. I think it must be, by its own nature. >>> Probably room for improvement and code transparency. But... are >>> Python-DEVs interested in the project?. That is the point :) >> >> As a concrete data point: - here are Dave's modifications to >> ceval.c for systemtap: >> http://bugs.python.org/review/14776/diff/5177/Python/ceval.c - here >> are your modifications to ceval.c for dtrace: >> http://bugs.python.org/review/13405/diff/6151/Python/ceval.c > > Unfair, because that code is not doing the same thing. > > Most of the extra complexity is there to deal with DTRACE ability to > provide meaningful stackframes, with Python code instead of CPython > evaluation loop. This is kind of magical. Antoine will correct me if I'm wrong, but I believe his point is less about the complexity of dtrace provision and more about how much of it lives in ceval.c: the systemtap provision also takes quite a bit of code, but almost all of that code is extracted into a separate file and only a pair of calls live in ceval.c You patch, because it adds quite a bit of complexity to ceval.c, makes reading it significantly more difficult (especially for people who don't care for probe implementations). Dave's more or less doesn't change the complexity of that file (people who don't care for probes don't have to follow the macros to know what they do). ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Use an empty def as a lambda
On 2013-09-19, at 23:17 , Nick Coghlan wrote: > On 20 Sep 2013 07:04, "Joe Pinsonault" wrote: >> >> I think it's a great idea personally. It's explicit and obvious. "lamda" > is too computer sciencey > > This suggestion has been made many times, occasionally with the associated > "must be contained in parentheses when used as an expression" caveat that > is needed to avoid making the language grammar ambiguous at the statement > level. Examples of some of these times: https://wiki.python.org/moin/AlternateLambdaSyntax https://mail.python.org/pipermail/python-dev/2006-February/060415.html https://mail.python.org/pipermail/python-dev/2006-February/thread.html#60415 Unless significant new insight is developed or Guido has picked the functional bug at dropbox, merely suggesting a name change from lambda to def (which has already been suggested in the past) probably isn't going to cut it. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Best practice for documentation for std lib
On 2013-09-22, at 12:16 , Nick Coghlan wrote: > > It's a bit of a pain, and we do occasionally get bug reports where the > docstrings get out of date, but it's the least bad of the currently > available options. Is it really less bad than allowing limited fine-grained use of autodoc? Not necessarily class-level and definitely not module-level, but function- and method-level autodoc could allow avoiding duplication and make it clearer that the prose and docstrings are getting out of sync. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Best practice for documentation for std lib
> On 22 Sep 2013, at 05:25, Benjamin Peterson wrote: > > There's not really much to do but maintain them separately. Truncate > the docstrings if it makes life easier. Autodoc could be enabled and allowed in a limited manner. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Best practice for documentation for std lib
On 2013-09-22, at 21:24 , Westley Martínez wrote: >> From: gvanros...@gmail.com [mailto:gvanros...@gmail.com] On Behalf Of Guido >> van Rossum >> Sent: Sunday, September 22, 2013 11:35 AM >> >> You seem to misunderstand the use of "autogeneration". It refers to >> generating >> the .rst docs from the docstrings in the source. And FWIW, I'm against that >> practice. > > Oh I see. Well in that case, the docstrings can still become outdated, > and so then the .rst docs will be outdated, too. The points here are that there's a single source of truth (so we can't have conflicting docstring and rst documentation), and documentation becoming outdated can be noticed from both docstring and published documentation. > It doesn't seem to > offer much benefit since you still have to keep both updated, plus you > have an extra tool that must be maintained. There is no extra tool, autodoc is part of the standard Sphinx distribution: http://sphinx-doc.org/ext/autodoc.html ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Why not support user defined operator overloading ?
On 2013-09-29, at 14:51 , 张佩佩 wrote: > Hello: > As far as I know, there is not a language support user defined operator > overloading. > Python3 can overloading belowed operators. > - negated > + unchanged > > - minus > + add > * multiplication > / division > //true division > % remainder > **power > (Do I miss something ?) ~ invert (unary) ()call . get attribute []get item <>right shift & binary and ^ xor | binary or And the inplace versions of most of these can be implemented separately, which can probably be counted as supplementary operators. > > If we can overloading these operators, why we can't overloading other > operators? > (like .* often used in matrix, U in set operation) This is more of a python-ideas subject. And one of the reasons likely is that it would require significantly reworking the grammar to handle a kind of user-defined opname (similar to name, but for operator tokens), with user-defined priority and associativity, and the ability to import operators (or define how and when operators become available compared to their definition) That's a huge amount of complexity with little to gain. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] summing integer and class
On 2013-10-03, at 15:45 , Igor Vasilyev wrote:
> Hi.
>
> Example test.py:
>
> class A():
>def __add__(self, var):
>print("I'm in A class")
>return 5
> a = A()
> a+1
> 1+a
>
> Execution:
> python test.py
> I'm in A class
> Traceback (most recent call last):
> File "../../test.py", line 7, in
>1+a
> TypeError: unsupported operand type(s) for +: 'int' and 'instance'
>
>
> So adding integer to class works fine, but adding class to integer fails.
> I could not understand why it happens. In objects/abstact.c we have the
> following function:
>
python-dev is about developing Python itself, not about developing in
Python, so that's the wrong mailing list for these kinds of question.
But FWIW the answer is that Python first tries 1.__add__(a), when that
fails (with NotImplemented) it uses the reflected method[0] which is
a.__radd__(1). Since that does not exist, the operation is invalid.
[0] http://docs.python.org/2/reference/datamodel.html#object.__radd__
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Optimization
On 2013-10-06, at 12:37 , Stephen J. Turnbull wrote: > > For me, the point about string "+=" being efficient (sometimes) isn't > that it is surprising compared to similar types, it's that it is > surprising for any immutable sequence type. It's clearly nitpicking, but ropes are immutable sequences with O(1) concatenation. Clojure's vectors also have a more-or-less-O(1) append (technically it's O(log32 n)) and one could implement a Python version of them. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] On suppress()'s trail blazing (was Re: cpython: Rename contextlib.ignored() to contextlib.ignore())
On 2013-10-17, at 18:06 , Barry Warsaw wrote: > On Oct 18, 2013, at 01:26 AM, Nick Coghlan wrote: >> By contrast, suppress() and redirect_stdout() are the *first* general >> purpose context managers added to contextlib since its incarnation in >> Python 2.5 (although there have been many various domain specific >> context manager additions elsewhere in the standard library). > > There's a fundamental conceptual shift here that's worth exploring more, and > which I think was first identified by RDM. > > Until now, context managers were at their heart (at least IMHO) about managing > "resources". A general resource might be an open file, or it might be a > database transaction, or even the current working directory. Context managers > (as expressed elegantly by the `with` statement) are used to ensure that a > resource acquired for some limited operation is - to Python's best ability - > "released" at the end of that operation, no matter what happens. E.g. the > file is closed even if there's a write error, or the current working directory > is restored to its original location. I think there's already a significant split between context managers which handle the lifecycle of a local resource (file, transaction) and those which purport to locally alter global-ish state (cwd, decimal.localcontext, logging.captureWarnings, redirect_stdout). And the latter worries me (much more than the very localized behavior of suppress) because I don't see any way to implement them safely and correctly when mixing it with coroutines in today's Python (some of them aren't even thread-safe), all of that while I expect coroutines will see significantly more use in the very near future with yield from and tulip's promotion of coroutine-style async. > Just look at the implementation to see this shift in perspective. It doesn't > use try/finally, it uses try/except. Transaction CMs will also use try/except: @contextmanager def transaction(): resource = open_tnx() try: yield resource resource.commit() except: resource.rollback() raise ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] On suppress()'s trail blazing (was Re: cpython: Rename contextlib.ignored() to contextlib.ignore())
On 2013-10-17, at 20:55 , Oscar Benjamin wrote: > On 17 October 2013 19:40, Xavier Morel wrote: >> I think there's already a significant split between context managers >> which handle the lifecycle of a local resource (file, transaction) and >> those which purport to locally alter global-ish state (cwd, >> decimal.localcontext, logging.captureWarnings, redirect_stdout). >> >> And the latter worries me (much more than the very localized behavior of >> suppress) because I don't see any way to implement them safely and >> correctly when mixing it with coroutines in today's Python (some of them >> aren't even thread-safe), all of that while I expect coroutines will see >> significantly more use in the very near future with yield from and >> tulip's promotion of coroutine-style async. > > I maybe misunderstanding how the coroutine-style async works but I > would have thought that it would be as simple as: don't use > global-state-restoring-context-managers around statements that yield > control You have to know which contextmanagers to what and how, and avoid them in these specific situations. I'm really bothered by these being unsafe by default. Technically they're already broken but the chance of them being used in such a context are low, whereas it wouldn't be unexpected for a user to e.g. create a local decimal context in a coroutine and *not* expect that local context to affect other coroutines running concurrently. > Context managers that actually save and restore *global* state are already > not thread-safe Hence my use of "global-ish", a global is process-local after all. A threadlocal is greenlet-global (for the greenlets running in that thread), and a greenlet-local is coroutine-global (although I don't expect multiplexing coroutines inside greenlets to be common, the natural consequence is that threadlocals are also coroutine-global). > , so concluding they are also not coroutine-safe (or > task-safe?) seems a small step. Yes, but not necessarily a step most users will remember to take, and of course the lack of thread-safety must be documented and noticed (as with warnings.catch_warnings[0]). Although I agree that > I'd be more worried about context manager that use thread-local state -- > there is no similar concept in Tulip. indeed. [0] not logging.captureWarnings() which I previously wrote, captureWarnings is not a context manager ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] On suppress()'s trail blazing (was Re: cpython: Rename contextlib.ignored() to contextlib.ignore())
On 2013-10-17, at 22:11 , Ethan Furman wrote: > On 10/17/2013 01:03 PM, Terry Reedy wrote: >> >> class suppress: >> def __init__(self, *exceptions): >> self.exceptions = exceptions >> def __exit__(self, etype, eval, etrace): >> return etype in self.exceptions > > This fails when etype is a subclass of the exceptions, as mentioned in the > original issue. That's fixed by using `issubclass` and does not infirm Terry's point does it? ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bug in the DELETE statement in sqlite3 module
> On 2016-06-15, at 08:40 , ninostephen mathew wrote:
>
> Respected Developer(s),
> while writing a database module for one of my applications in python I
> encountered something interesting. I had a username and password field in my
> table and only one entry which was "Admin" and "password". While debugging I
> purposefully deleted that record. Then I ran the same statement again. To my
> surprise, it got execute. Then I ran the statement to delete the user "admin"
> (lowercase 'a') which does not exist in the table. Surprisingly again is got
> executed even though the table was empty. What I expected was an error
> popping up. But nothing happened. I hope this error gets fixed soon. The
> code snippet is given below.
>
> self.cursor.execute(''' DELETE FROM Users WHERE username =
> ?''',(self.username,))
Despite Python bundling sqlite, the Python mailing list is not
responsible for developing SQLite (only for the SQLite bindings
themselves) so this is the wrong mailing list.
That being said, the DELETE statement deletes whichever records in the
table match the provided predicate. If no record matches the predicate,
it will simply delete no record, that is not an error, it is the exact
expected and documented behaviour for the statement in SQL in general
and SQLite in particular.
See https://www.sqlite.org/lang_delete.html for the documentation of the
DELETE statement in SQLite.
While you should feel free to report your expectations to the SQLite
project or to the JTC1/SC32 technical committee (which is responsible
for SQL itself) I fear that's what you will get told there, and that you
are about 30 years too late to try influence such a core statement of
the language.
Not that it would have worked I'd think, I'm reasonably sure the
behaviour of the DELETE statement is a natural consequence of SQL's set-
theoretic foundations: DELETE applies to a set of records, regardless of
the set's cardinality.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyWeakref_GetObject() borrows its reference from... whom?
> On 2016-10-10, at 11:05 , Devin Jeanpierre wrote: > The term "borrowed" is supposed to imply a sensible scope during which you're > free to use the object, and weakrefs don't have that (except for what is > granted by the GIL), so this does sound wacky. I bet it was for performance. Especially as it handles both getting an object from a weakref and checking whether the weakref is still alive. OTOH it could be an enshrined bug, http://bugs.python.org/issue520087 fixed a discrepancy between the doc and the implementation by matching the doc to the implementation (of returning a borrowed ref'). Also of note, pypy developers have been reporting issues with that specific API since ~2010[0][1], and IIRC they have added a PyWeakref_LockObject to cpyext. [0] http://bugs.python.org/issue8578 [1] http://bugs.python.org/issue16602#msg177272___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Micro-optimizations by adding special-case bytecodes?
> On 2017-05-24, at 20:07 , Ben Hoyt wrote: > > Hi folks, > > I was looking at some `dis` output today, and I was wondering if anyone has > investigated optimizing Python (slightly) by adding special-case bytecodes > for common expressions or statements involving constants? Python 3.6 added an opcode specifically for dicts with constant keys: https://bugs.python.org/issue27140. Though I guess that's a slightly different case as it's not a peephole-fused opcode. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Micro-optimizations by adding special-case bytecodes?
> On 2017-05-24, at 20:26 , Xavier Morel wrote: > >> On 2017-05-24, at 20:07 , Ben Hoyt wrote: >> >> Hi folks, >> >> I was looking at some `dis` output today, and I was wondering if anyone has >> investigated optimizing Python (slightly) by adding special-case bytecodes >> for common expressions or statements involving constants? > > Python 3.6 added an opcode specifically for dicts with constant keys: > https://bugs.python.org/issue27140. Though I guess that's a slightly > different case as it's not a peephole-fused opcode. And followup, Python 2.7 did add fused opcodes related to conditional: http://bugs.python.org/issue4715. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: REPL output bug
> On 16 Jun 2020, at 08:51, Greg Ewing wrote: > > On 16/06/20 12:20 pm, Steven D'Aprano wrote: >> The whole point of the REPL is to evaluate an >> expression and have the result printed. (That's the P in REPL :-) > > Still, it's a bit surprising that it prints results of > expressions within a compound statement, not just at the > top level. For what that’s worth, 2.7 seems to have the same behaviour, every statement with a non-None result gets echoed even if it is not the top level statement e.g. Python 2.7.17 (default, April 15 2020, 17:20:14) [GCC 7.5.0] on linux2 Type “help”, “copyright”, “credits” or “license” for more information. >>> for i in range(3): i ... 0 1 2 >>> ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/HSU7EIKRX37SZ4TZPG6N52YKVLETZRN3/ Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-Dev] Partial function application 'from the right'
On 5 Feb 2009, at 23:54 , Steven D'Aprano wrote: Raymond Hettinger wrote: The arguments for and against the patch could be brought against partial() itself, so I don't understand the -1's at all. Quite so, but that doesn't justify adding more capabilities to partial(). I concur with Collin. Lever arguments are a road to bloat. One person's "bloat" is another person's rich and complete toolbox. > "In for a penny, in for a pound" is not a language design principle. Neither are "slippery slope" arguments. One of the real problems with partial() and its variants is that they provide almost no advantage over an equivalent lambda. How about speed? I don't have a recent version of Python here to test, but my recollection is that partial is significantly faster than lambda. And even if it currently isn't, there could be (is?) more opportunity to optimize partial. I guess that the voting on this is going to be fall along functional lines: those who like functional languages will vote +1 on partial and co, and those who don't will vote -1. While I don't dislike partial(), I'd rather see one good use-case for partial_right() to be removed: built-ins that don't accept keywords. From Ben North's post starting this thread: "I find 'functools.partial' useful, but occasionally I'm unable to use it because it lacks a 'from the right' version. E.g., to create a function which splits a string on commas, you can't say # Won't work when called: split_comma = partial(str.split, sep = ',') and to create a 'log to base 10' function, you can't say # Won't work when called: log_10 = partial(math.log, base = 10.0) because str.split and math.log don't take keyword arguments." Wouldn't a `flip` function (reverse the order of the function's arguments) be more flexible and general than a `partial_right` one? Your first case would become # we're not ignoring any argument, so we have to provide `maxsplit` split_comma = partial(flip(str.split), None, ',') and the second one would yield log_10 = partial(flip(math.log), 10.0) and if we only want to fill-in the rightmost argument, we can flip the result to get the original order back: split_5 = flip(partial(flip(str.split), 5)) While better kwargs support would be even better, there probably always will be kwarg-less functions/methods, so the ability to partially apply from the right stays interesting. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] (try-except) conditional expression similar to (if-else) conditional (PEP 308)
On 6 Aug 2009, at 00:22 , Jeff McAninch wrote: I'm new to this list, so please excuse me if this topic has been discussed, but I didn't see anything similar in the archives. I very often want something like a try-except conditional expression similar to the if-else conditional. I fear this idea is soon going to extend to all compound statements one by one. Wouldn't it be smarter to fix the issue once and for all by looking into making Python's compound statements (or even all statements without restrictions) expressions that can return values in the first place? Now I don't know if it's actually possible, but if it is the problem becomes solved not just for try:except: (and twice so for if:else:) but also for while:, for: (though that one's already served pretty well by comprehensions) and with:. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] (try-except) conditional expression similar to (if-else) conditional (PEP 308)
On 8 Aug 2009, at 08:02 , Steven D'Aprano wrote: On Fri, 7 Aug 2009 08:22:14 pm Kristján Valur Jónsson wrote: Unless I am very much mistaken, this is the approach Ruby takes. Everything is an expression. For example, the value of a block is the value of The last expression in the block. Copying what other languages do is not necessarily a bad thing, but that would fail both "explicit is better than implicit" and "in the face of ambiguity, avoid the temptation to guess". The first objection one might be able to give, you maybe, but the second one? Where's the ambiguity in "compound statements return the result of the last evaluated expression"? It's not immediately obvious to me why the last expression should be given that privileged rule. Why not the first expression? Because it wouldn't make any sense? When you're computing something, the value you want is the one at the end of the computation (usually called a result), not some random one somewhere else. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] functools.compose to chain functions together
On 14 Aug 2009, at 20:39 , Jason R. Coombs wrote: I've heard it said that Python is not a functional language, but if that were really the case, then functools would not exist. In addition to the example described above, I've had multiple occasions where having a general purpose function composition function would have simplified the implementation by providing a basic functional construct. It's not like a basic variable-arity composition function is hard to implement though, it's basically: def compose(*funcs): return reduce(lambda f1, f2: lambda v: f1(f2(v)), funcs) it'll turn compose(a, b, c, d)(value) into a(b(c(d(value ___ 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/archive%40mail-archive.com
Re: [Python-Dev] functools.compose to chain functions together
On 17 Aug 2009, at 09:43 , Steven D'Aprano wrote: On Mon, 17 Aug 2009 08:10:16 am Martin v. Löwis wrote: I don't think he did. Comparing it to the one obvious solution (use a lambda expression), his only reasoning was "it is much easier to read". I truly cannot believe that a compose function would be easier to read to the average Python programmer: if you have def foo(data): return compose(a, b(data), c) what would you expect that to mean? foo is a factory function that, given an argument `data`, generates a function b(data), then composes it with two other functions a and c, and returns the result, also a function. From his messages, I think Martin's issue with `compose` is with the composition order rather than the fact that it "pipes" functions: compose uses the mathematical order, (f ∘ g)(x) = f(g(x)) (so g, the last function of the composition, is applied first), rather than a "shell pipe" order of `(f >>> g)(x) = g(f(x))` (where g, the last function of the composition, is applied last). For the record, Haskell makes compose a built-in operator: http://www.haskell.org/haskellwiki/Function_composition Yes, but Haskell also has a left-to-right composition, the (>>>) operator: http://haskell.org/ghc/docs/latest/html/libraries/base/Control-Arrow.html#v :>>> ___ 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/archive%40mail-archive.com
Re: [Python-Dev] default of returning None hurts performance?
On 1 Sep 2009, at 03:03 , Gregory P. Smith wrote: On Mon, Aug 31, 2009 at 5:01 PM, Greg Ewing >wrote: Antoine Pitrou wrote: Did your coworker run any timings instead of basing his assumptions on bytecode size? In any case, what are you suggesting -- that the last value returned by a function call in the body should be the default return value? I don't think the unpredictability that would introduce would be a good idea. gads no. we're not shell or perl! don't do that :) "We" are not Erlang, Smalltalk, OCaml or Haskell either, sadly. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] default of returning None hurts performance?
On 1 Sep 2009, at 02:01 , Greg Ewing wrote: I don't think the unpredictability that would introduce would be a good idea. I fail to grasp the unpredictability of "the last expression evaluated in the body of a function is its return value". It couldn't work in Python because statements aren't expressions, therefore I think def foo(): if cond: 3 else: 4 would break (given if:else: doesn't return a value, the function couldn't have a return value), but in languages where everything is an expression (where if:else: does return a value) there's nothing unpredictable about it. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] [OT] implicit return values
On 1 Sep 2009, at 15:25 , Antoine Pitrou wrote: Le mardi 01 septembre 2009 à 15:09 +0200, Xavier Morel a écrit : "We" are not Erlang, Smalltalk, OCaml or Haskell either, sadly. Well, feel free to prefer an unreadable language if you want :) Smalltalk or Haskell are hardly inherently unreadable. And it's not like the Python community never lifts features from such languages, so obviously they do (some at least) things right. it will most certainly be shot down anyway Yep, so there's not much point in bringing it up there. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] [OT] implicit return values
On 2 Sep 2009, at 00:10 , Greg Ewing wrote: Le mardi 01 septembre 2009 à 15:09 +0200, Xavier Morel a écrit : "We" are not Erlang, Smalltalk, OCaml or Haskell either, sadly. IIRC, the default return value of a Smalltalk method is self, not the last thing evaluated. Methods yes (and that's one of the few Smalltalk design "features" I consider truly dumb, considering it has message cascading), but I was referring to blocks rather than methods and the return value of blocks is the last evaluated expression. (And no, that's not going to happen in Python either -- the BDFL has rejected similar suggestions on previous occasions.) I know. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Decorator syntax
On 2 Sep 2009, at 12:15 , Rob Cliffe wrote: @Identity(DecoList[0])# THIS WORKS def foo(): pass For what it's worth, you don't need an id function, you can simply write @itemgetter(0)(decorators) def foo(): 'whatever' or @decorators.__getitem__(0) def foo(): 'whatever' ___ 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/archive%40mail-archive.com
Re: [Python-Dev] [OT] implicit return values
On 3 Sep 2009, at 23:33 , Greg Ewing wrote: Xavier Morel wrote: Methods yes (and that's one of the few Smalltalk design "features" I consider truly dumb, considering it has message cascading) Cascading is something different -- it's for sending multiple messages to the *same* receiver. It's not dumb to have both. I know what cascading is for. The issue is that with message cascading + the "yourself" message, you *never* need to chain on self (you can just cascade and -- if you end up needing the instance to drop down at the end of the cascade -- send `yourself`). Chaining on self is completely redundant in smalltalk as the purpose of this pattern is *also* to send a sequence of messages to the same receiver (something message cascading already handles & guarantees). Therefore defaulting method to self-chaining is very dumb and serves no purpose whatsoever. It doesn't make the language easier to use, less verbose or more practical. It just wastes return values. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Top-posting on this list
On 11 Oct 2009, at 18:07 , MRAB wrote: Didn't the iPhone also lack cut-and-paste? It did, but given text selection is a near-mandatory requirement to cutting text (and pasting isn't very useful if you can't put anything into the clipboard) those were implied consequences of the lack of selection. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PyPI comments and ratings, *really*?
On 13 Nov 2009, at 00:35 , Antoine Pitrou wrote: > Masklinn masklinn.net> writes: >> >> And then user will probably ask why you're not answering the question since >> you're here anyway, or might go >> as far as telling you that if you're not going to help you might as well not >> answer. > As I said, you are regarding the user as an idiot or as a troll. I don't think so, but we might disagree on either definition, or both. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PyPI comments and ratings, *really*?
On 13 Nov 2009, at 00:34 , Jesse Noller wrote: > That's because as an author/maintainer - we have methods of giving > feedback and communication. Why not rate ( or auto-rate) packages on > objective criteria? > > E.g.: tests and test coverage, docs, installs on python version X, Y, > Z, works on windows, etc? Because there are lots of subjective criteria which are still very useful to users? The feeling of the API, the completeness of the library or its flexibility, etc…? If pypi one day has a CPAN-style buildbot farm allowing it to test the package on any platform under the sun, that can be included, the tests can be included as well but given the number of testing solutions (and coverage discovery associated) that would be quite an undertaking. And as far as docs go, what would be the criterion? "Has documentation"? How do you define "has documentation"? Has auto-extracted documentation from the docstrings? Has a README? Has a complete sphinx package? I don't think there's much that you can rate "objectively" about documentation. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PyCon Keynote
On 26 Jan 2010, at 17:09 , Glenn Linderman wrote: > >>> Why can't we just be like the rest of the universe and have one >>> icon type for packages and one icon type for applications. >>> >>> Double click them and they get filed in the right place. >>> >> >> What platform files things in the right place when you double click >> them? > > This is still an open question. Not quite platform-level, but I recall this coming up in the "indie" mac development scene a few months ago [1]: Mac apps are usually a single .app package (a file tree which looks like a single file) which is "installed" by copying it into /Applications. But that isn't mandatory by any mean, and apparently new users to the platform forget that step and just launch the application from the download folder (if the application was in a zip and got unzipped) or from the .dmg archive (which is basically a mounted read-only disk image). Or they drop the application in the doc itself, which creates a shortcut to the content of the dmg or to the unzipped application in ~/downloads. Neither of these are very good, though they do work (generally) the former makes a mess out of the download folder, and the latter requires having thousands of dmgs open which is a pain (and the user has to keep the dmg files). So in the line of Sparkle, for those and other reasons, some applications started asking if they should move themselves to the Applications folder when launched from out of it. Two of these are Delicious Library and The Hit List [2] whose developers open-sourced the application-moving code [3]. 1: http://daringfireball.net/2009/09/how_should_mac_apps_be_distributed 2: http://www.potionfactory.com/node/251 3: http://github.com/potionfactory/LetsMove/ ___ 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/archive%40mail-archive.com
Re: [Python-Dev] argparse ugliness
I don't believe argparse's action specification scheme is bad either, but On 6 Mar 2010, at 13:50 , Nick Coghlan wrote: > > you wouldn't get the static name checking that is > the primary benefit of using named constants in less dynamic languages. There are quite a few tools which do handle static checking of that kind of stuff, so while Python itself doesn't provide it (as a builtin) it's not like you can't get it some other way. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] argparse ugliness
On 8 Mar 2010, at 16:53 , David Stanek wrote:
>
> On Mon, Mar 8, 2010 at 10:40 AM, Steven Bethard
> wrote:
>>
>> In argparse, unlike optparse, actions are actually defined by objects
>> with a particular API, and the string is just a shorthand for
>> referring to that. So:
>>
>> parser.add_argument ('--plot', action='store_true')
>>
>> is equivalent to:
>>
>> parser.add_argument('--plot', argparse._StoreTrueAction)
>>
>> Because the names are so long and you'd have to import them, I've left
>> them as private attributes of the module, but if there's really
>> demand, we could rename them to argparse.StoreTrueAction, etc.
>>
>
> Any reason not to do something like:
>
> from argparse import actions
> ...
> parser.add_argument('--plot', actions.store_true)
>
> Basically a small namespace for the constants.
action is taken from **kwargs, not from a positional argument as *args
is a sequence of option strings (so you can write
add_argument('-p', '/p', '--plot', '--land-mass')). So you'd have to write
add_argument('--plot', action=actions.store_true) which is straight from
the department of redundant redundancies.
An option would be
parser.add(actions.StoreTrue('--plot'))
but I'm not sure this makes any sense API-wise, and it would probably make
the code a lot messier as the parser would have to reach into the action
to get the information it needs. Either that, or the action would be an *arg
and argparse would have to walk all of its *args type-testing each one to find
if there's an action anywhere.
___
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/archive%40mail-archive.com
Re: [Python-Dev] Why is nan != nan?
On 26 Mar 2010, at 18:40 , Casey Duncan wrote: > > > On Mar 25, 2010, at 7:19 PM, P.J. Eby wrote: > >> At 11:57 AM 3/26/2010 +1100, Steven D'Aprano wrote: >>> But they're not -- they're *signals* for "your calculation has gone screwy >>> and the result you get is garbage", so to speak. You shouldn't even think >>> of a specific NAN as a piece of specific garbage, but merely a label on the >>> *kind* of garbage you've got (the payload): INF-INF is, in some sense, a >>> different kind of error to log(-1). In the same way you might say "INF-INF >>> could be any number at all, therefore we return NAN", you might say "since >>> INF-INF could be anything, there's no reason to think that INF-INF == >>> INF-INF." >> >> So, are you suggesting that maybe the Pythonic thing to do in that case >> would be to cause any operation on a NAN (including perhaps comparison) to >> fail, rather than allowing garbage to silently propagate? >> >> In other words, if NAN is only a signal that you have garbage, is there >> really any reason to keep it as an *object*, instead of simply raising an >> exception? Then, you could at least identify what calculation created the >> garbage, instead of it percolating up through other calculations. >> >> In low-level languages like C or Fortran, it obviously makes sense to >> represent NAN as a value, because there's no other way to represent it. But >> in a language with exceptions, is there a use case for it existing as a >> value? > > If a NaN object is allowed to exist, that is a float operation that does not > return a real number does not itself raise an exception immediately, then it > will always be possible to get (seemingly) nonsensical behavior when it is > used in containers that do not themselves "operate" on their elements. How about raising an exception instead of creating nans in the first place, except maybe within specific contexts (so that the IEEE-754 minded can get their nans working as they currently do)? That way, there cannot be any nan-induced seemingly nonsensical behavior except within known scopes. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Very Strange Argument Handling Behavior
On 16 Apr 2010, at 23:31 , Guido van Rossum wrote: > > +1. > > Apparently dict(x, **y) is going around as "cool hack" for "call > x.update(y) and return x". Personally I find it more despicable than > cool. This description doesn't make sense since `dict(x, **y)` returns not an updated `x` but a new dictionary merging `x` and `y`. And that's how (and why) I use it, it's simpler (and — I believe — more readable) to write `z = dict(x, **y)` than `z = dict(x); z.update(y)`, since Python doesn't overload addition as it does for lists: l3 = l1 + l2 works and is equivalent to l3 = list(l1); l3.extend(l2) but there is no easy way to say that with dicts, at the moment. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Set the namespace free!
On 2010-07-22, at 14:45 , Simon Brunning wrote:
> On 22 July 2010 15:04, Bartosz Tarnowski
> wrote:
>> What should I do then, when the attribute is a reserver word?
>
> You would use elem.getattr('param'). That's what it's for.
getattr(elem, 'param') I believe, rather than elem.getattr('param')
___
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/archive%40mail-archive.com
Re: [Python-Dev] Atlassian and bitbucket merge
On 2010-09-29, at 11:50 , Antoine Pitrou wrote: > On Wed, 29 Sep 2010 09:03:29 +0200 > Dirkjan Ochtman wrote: >> >> Anyway, I don't think using Bitbucket buys us much. It could be nice >> to keep a mirror there for redundancy and because it might make >> contributing slightly easier for non-committers, but it won't allow >> doing all kinds of custom hooks the way we could do with hg.p.o, >> AFAICT. > > Using Bitbucket seems mainly useful if you need the whole suite of > services (issue tracker, wiki, etc.). > The most useful features are probably the follow and fork, but for a project as big as Python I'm not sure those are going to be used a lot. The question then becomes whether Python development workflow will remain as-is or would more to a "pull-request" model via bitbucket. If it's negative, then I see no intrinsic value in the main server being on bitbucket. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Atlassian and bitbucket merge
On 2010-09-29, at 15:26 , Tarek Ziadé wrote: > On Wed, Sep 29, 2010 at 2:36 PM, wrote: >> On 01:13 am, st...@holdenweb.com wrote: >>> I see that Atlassian have just taken over BitBucket, the Mercurial >>> hosting company. IIRC Atlassian offered to host our issue tracking on >>> JIRA, but in the end we decided to eat our own dog food and went with >>> roundup. >>> >>> I'm wondering if they'd be similarly interested in supporting our Hg >>> server. Or is self-hosting the only acceptable solution? From recent >>> mail it looks likes we may be up and running on Hg fairly soon. >> >> I know of two medium sized projects (smaller than CPython) that are >> switching away from BitBucket's free services because of their poor >> reliability. > > Me too, but I am pretty sure the reliability is going to drastically > change in the upcoming months. If Atlassian took over this probably > means Bitbucket will have more people to work on the project and some > help from the Atlassian Ops. That's really a good news ! According to Atlassian's announcement of the acquisition, they've already gotten started on that: >> Performance enhancements > Bitbucket's performance has lagged due to poor infrastructure and > lack of IT resources. Recently, Bitbucket customer repositories were > migrated from an EC2 storage system to the Contegix data center, the > same ISV that Atlassian uses for its hosted tools. Atlassian has hired > a full-time IT resource to continue to improve the Bitbucket service > to work on delivering even more services and improvements. It should > be noted that all Bitbucket users are now covered under the Atlassian > Terms of Use. There is heaps more work to do to provide the legendary > service that Atlassian customers have come to expect, and we fully > intend to live up to that promise. >> Feature updates > We've tripled the Bitbucket developer team to ramp up feature > improvements and the frequency of releases. Over the next few months, > users can expect to see more UI improvements, feature enhancements, > and integration with Atlassian's developer stack. Even though the team > has already tripled, we're still hiring (hint hint)! YMMV. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Inclusive Range
On 2010-10-04, at 05:04 , Eviatar Bach wrote: > Hello, > > I have a proposal of making the range() function inclusive; that is, > range(3) would generate 0, 1, 2, and 3, as opposed to 0, 1, and 2. Not only > is it more intuitive, it also seems to be used often, with coders often > writing range(0, example+1) to get the intended result. It would be easy to > implement, and though significant, is not any more drastic than changing > print to a function in Python 3. Of course, if this were done, slicing > behaviour would have to be adjusted accordingly. > > What are your thoughts? Same as the others: 0. This is a discussion for python-ideas, I'm CCing that list 1. This is a major backwards compatibility breakage, and one which is entirely silent (`print` from keyword to function wasn't) 2. It loses not only well-known behavior but interesting properties as well (`range(n)` has exactly `n` elements. With your proposal, it has ``n+1`` breaking ``for i in range(5)`` to iterate 5 times as well as ``for i in range(len(collection))`` for cases where e.g. ``enumerate`` is not good enough or too slow) 3. As well as the relation between range and slices 4. I fail to see how it is more intuitive (let alone more practical, see previous points) 5. If you want an inclusive range, I'd recommend proposing a flag on `range` (e.g. ``inclusive=True``) rather than such a drastic breakage of ``range``'s behavior. That, at least, might have a chance. Changing the existing default behavior of range most definitely doesn't. I'd be −1 on your proposal, −0 on adding a flag to ``range`` (I can't recall the half-open ``range`` having bothered me recently, if ever) ___ 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/archive%40mail-archive.com
Re: [Python-Dev] [Python-ideas] minmax() function returning (minimum, maximum) tuple of a sequence
On 2010-10-11, at 07:56 , Carl M. Johnson wrote: > On Sun, Oct 10, 2010 at 2:55 PM, Zac Burns wrote: >> This could be generalized and placed into itertools if we create a function >> (say, apply for lack of a better name at the moment) that takes in an >> iterable and creates new iterables that yield each from the original >> (avoiding the need for a list) holding only one in memory. Then you could >> pass the whatever function you wanted to run the iterables over an get the >> result back in a tuple. > > Time machine partially beat you to this one. Look at the docs on itertools.tee > >tee(it, n=2) --> (it1, it2 , ... itn) splits one iterator into n > > Can be used like so: > it = iter(range(100)) it1, it2 = itertools.tee(it) max(it1) > 99 min(it2) > 0 > > This doesn't quite have the memory characteristics you describe That's an understatement. As the documentation indicates, if you're going to fully consume the iterator the first time around instead of iterating both in near-lockstep (combining islice and map for instance) you're better off serializing to a list and then using that list twice, memory-wise. > but it's about as good as you can expect in a single threaded environment. You could also have coroutines, but they cooperate explicitly so you'd have to "fix" min and max (and any other function you can get your hands on, really) in order to allow them to act as coroutines, I think. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Import and unicode: part two
On 2011-01-25, at 04:26 , Toshio Kuratomi wrote: > > * If you can pick a set of encodings that are valid (utf-8 for Linux and > MacOS HFS+ uses UTF-16 in NFD (actually in an Apple-specific variant of NFD). Right here you've already broken Python modules on OSX. And as far as I know, Linux software/FS generally use NFC (I've already seen this issue cause trouble) ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Proposal / Questions about OrderedDict literals and/or faster C implementation
On 2011-02-10, at 21:47 , Éric Araujo wrote: > Ideas are usually discussed first on python-ideas to assess usefulness, > get the pulse of the community, beat the API into shape and such things > before coming up to python-dev. (A number of core devs are on both lists.) > > You may want to search the mail archive for all the previous threads > about adding a C version and literal notation for ordered dicts. Indeed, there's been a discussion on this very subject not three weeks ago: http://mail.python.org/pipermail/python-ideas/2011-January/009037.html I'm guessing this request is going to get more common for some time, as people are getting aware Ruby switched its Hash implementation to an ordered dict in 1.9 (well they didn't exactly switch anything around, they added back and next pointers to their dict cells) ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Const-correctness in C-API Object Protocol
On 2011-02-22, at 21:55 , Antoine Pitrou wrote: > On Tue, 22 Feb 2011 21:48:51 +0100 > Stefan Behnel wrote: >> Reid Kleckner, 22.02.2011 21:21: >>> On Tue, Feb 22, 2011 at 2:09 PM, Eric Smith wrote: Also changing it now would be a giant hassle, leading to so-called "const poisoning" where many, many APIs need to be changed before everything would again work. >>> >>> The poisoning will not break any users of the API, though, since they >>> can pass const and non-const pointers. Internally Python would have >>> to go through and add const keywords as appropriate when passing >>> strings around. IMO it's worth it to not cause this warning for >>> users. >> The problem is that Python's C-API functions are used both internally and >> externally, so changes like this can easily impact other public API >> functions because the function being changed uses them. > How so? If the parameters are passed from the newly const'ed function to an other public-API function, that one will have to be const'ed as well (or the const will have to be cast away which generally isn't considered good style and may lead to UBs), which may cascade into yet an other public-API function, the end result being that numerous functions would have to be const'ed: > Adding const qualification may propagate through a program; as you > add const qualifiers, still more become necessary. This phenomenon is > sometimes called "const-poisoning." Const-poisoning can frequently > lead to violations of recommendation EXP05-C. Do not cast away a const > qualification. While const qualification is a good idea, the costs may > outweigh the value in the remediation of existing code. https://www.securecoding.cert.org/confluence/display/seccode/STR05-C.+Use+pointers+to+const+when+referring+to+string+literals ___ 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/archive%40mail-archive.com
Re: [Python-Dev] %-formatting depracation
On 2011-02-23, at 12:30 , Hrvoje Niksic wrote:
> On 02/22/2011 11:03 PM, Antoine Pitrou wrote:
>> I think there are many people still finding %-style more practical for
>> simple uses,
>
> It's also a clash of cultures. People coming from a C/Unix background
> typically find %-style format obvious and self-explanatory, while people
> coming from Java/DotNET background feel the same way about {}-style formats.
For Java it's debatable: the Java 5 string formatting APIs are all printf-style
(java.io.PrintStream#printf[0], String#format[1], java.util.Formatter[2]).
The older java.text.MessageFormat[3] (still used a lot for property lists as
it's built for localization among other things) does use {}-style, though one
quite different than Python's.
[0]
http://download.oracle.com/javase/1.5.0/docs/api/java/io/PrintStream.html#printf(java.lang.String,%20java.lang.Object...)
[1]
http://download.oracle.com/javase/1.5.0/docs/api/java/lang/String.html#format(java.lang.String,%20java.lang.Object…)
[2] http://download.oracle.com/javase/1.5.0/docs/api/java/util/Formatter.html
[3]
http://download.oracle.com/javase/1.5.0/docs/api/java/text/MessageFormat.html
___
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/archive%40mail-archive.com
Re: [Python-Dev] Proposal for Python 3.3: dependence injection
On 2011-03-25, at 10:22 , Simon Cross wrote: > On Fri, Mar 25, 2011 at 1:25 AM, 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 advantage of such an >> approach is that it would then work for 3rd party libraries that >> create sockets, without requiring any further modification. > > -2. That wouldn't allow one to use normal sockets in one 3rd party > library and special sockets in another 3rd party library. > > Schiavo > Simon Or even in "first-party" code (in the stdlib) to set different timeouts on different APIs (say, an xmlrpclib.ServerProxy and an IMAP4 client). For instance, currently as far as I can tell setting a socket timeout on an xmlrpclib.ServerProxy without setting a global timeout involves: * subclassing all of xmlrpclib.Serverproxy, xmlrpclib.Transport, httplib.HTTP and httplib.HTTPConnection * overloading __init__ on the ServerProxy subclass (and on Transport if the timeout is to be a parameter) * overloading make_connection on the Transport subclass (in order to use the HTTP subclass and propagate the timeout) * overloading _connection_class on the HTTP subclass * overloading connect on the HTTPConnection class This *could* be solved by wrapping a socket-related thread-local context manager around each call resulting in the creation of a socket, but these call sites may not even be under control. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Status of json (simplejson) in cpython
On 2011-04-16, at 16:52 , Antoine Pitrou wrote: > Le samedi 16 avril 2011 à 16:42 +0200, Dirkjan Ochtman a écrit : >> On Sat, Apr 16, 2011 at 16:19, Antoine Pitrou wrote: >>> What you're proposing doesn't address the question of who is going to >>> do the ongoing maintenance. Bob apparently isn't interested in >>> maintaining stdlib code, and python-dev members aren't interested in >>> maintaining simplejson (assuming it would be at all possible). Since >>> both groups of people want to work on separate codebases, I don't see >>> how sharing a single codebase would be possible. >> >> From reading this thread, it seems to me like the proposal is that Bob >> maintains a simplejson for both 2.x and 3.x and that the current >> stdlib json is replaced by a (trivially changed) version of >> simplejson. > > The thing is, we want to bring our own changes to the json module and > its tests (and have already done so, although some have been backported > to simplejson). Depending on what those changes are, would it not be possible to apply the vast majority of them to simplejson itself? Furthermore, now that python uses Mercurial, it should be possible (or even easy) to use a versioned queue (via MQ) for the trivial adaptation, and the temporary alterations (things which will likely be merged back into simplejson but are not yet, stuff like that) should it not? ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Status of json (simplejson) in cpython
On 2011-04-16, at 17:25 , Antoine Pitrou wrote: > Le samedi 16 avril 2011 à 17:07 +0200, Xavier Morel a écrit : >> On 2011-04-16, at 16:52 , Antoine Pitrou wrote: >>> Le samedi 16 avril 2011 à 16:42 +0200, Dirkjan Ochtman a écrit : >>>> On Sat, Apr 16, 2011 at 16:19, Antoine Pitrou wrote: >>>>> What you're proposing doesn't address the question of who is going to >>>>> do the ongoing maintenance. Bob apparently isn't interested in >>>>> maintaining stdlib code, and python-dev members aren't interested in >>>>> maintaining simplejson (assuming it would be at all possible). Since >>>>> both groups of people want to work on separate codebases, I don't see >>>>> how sharing a single codebase would be possible. >>>> >>>> From reading this thread, it seems to me like the proposal is that Bob >>>> maintains a simplejson for both 2.x and 3.x and that the current >>>> stdlib json is replaced by a (trivially changed) version of >>>> simplejson. >>> >>> The thing is, we want to bring our own changes to the json module and >>> its tests (and have already done so, although some have been backported >>> to simplejson). >> >> Depending on what those changes are, would it not be possible to apply >> the vast majority of them to simplejson itself? > > Sure, but the thing is, I don't *think* we are interested in backporting > stuff to simplejson much more than Bob is interested in porting stuff to > the json module. I was mostly thinking it could work the other way around, really: simplejson seems to move slightly faster than the stdlib's json (though it's not a high-churn module either these days), so improvements (from Python and third parties alike) could be applied there first and then forward-ported, rather than the other way around. > I've contributed a couple of patches myself after they were integrated > to CPython (they are part of the performance improvements Bob is talking > about), but that was exceptional. Backporting a patch to another project > with a different directory structure, a slightly different code, etc. is > tedious and not very rewarding for us Python core developers, while we > could do other work on our limited free time. Sure, I can understand that, but wouldn't it be easier if the two versions were kept in better sync (mostly removing the "slightly different code" part)? >> Furthermore, now that python uses Mercurial, it should be possible (or >> even easy) to use a versioned queue (via MQ) for the trivial >> adaptation, and the temporary alterations (things which will likely be >> merged back into simplejson but are not yet, stuff like that) should >> it not? > Perhaps, perhaps not. That would require someone motivated to put it in > place, ensure that it doesn't get in the way, document it, etc. > Honestly, I don't think maintaining a single stdlib module should > require such an amount of logistics. I don't think mercurial queues really amount to logistic, it takes a bit of learning but fundamentally they're not much work, and make synchronization with upstream packages much easier. Which would (I believe) benefit both projects and — ultimately — language users by avoiding too extreme differences (on both API/features and performances). I'm thinking of a relation along the lines of Michael Foord's unittest2 (except maybe inverted, in that unittest2 is a backport of a next version's unittest) ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Linus on garbage collection
On 2011-05-07, at 03:39 , Glyph Lefkowitz wrote: > > I don't know if there's a programming language and runtime with a real-time, > VM-cooperating garbage collector that actually exists today which has all the > bells and whistles required to implement an OS kernel, so I wouldn't give the > Linux kernel folks too much of a hard time for still using C; but there's > nothing wrong with the idea in the abstract. Not sure it had all those bells and whistles, and there were other issues, but I believe Lisp Machines implemented garbage collection at the hardware (or at least microcode) level, and the OS itself provided a pretty direct interface to it (it was part of the core services). ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Python 3.x and bytes
On 2011-05-19, at 07:28 , Georg Brandl wrote: > On 19.05.2011 00:39, Greg Ewing wrote: >> Ethan Furman wrote: >> >>> some_var[3] == b'd' >>> >>> 1) a check to see if the bytes instance is length 1 >>> 2) a check to see if >>> i) the other object is an int, and >>> 2) 0 <= other_obj < 256 >>> 3) if 1 and 2, make the comparison instead of returning NotImplemented? >> >> It might seem convenient, but I'd worry that it would lead to >> even more confusion in other ways. If someone sees that >> >>some_var[3] == b'd' >> >> is true, and that >> >>some_var[3] == 100 >> >> is also true, they might expect to be able to do things >> like >> >>n = b'd' + 1 >> >> and get 101... or maybe b'e'... > > Maybe they should :) But why wouldn't "they" expect `b'de' + 1` to work as well in this case? If a 1-byte bytes is equivalent to an integer, why not an arbitrary one as well? ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Python 3.x and bytes
On 2011-05-19, at 09:49 , Nick Coghlan wrote:
> On Thu, May 19, 2011 at 5:10 AM, Eric Smith wrote:
>> On 05/18/2011 12:16 PM, Stephen J. Turnbull wrote:
>>> Robert Collins writes:
>>>
>>> > Its probably too late to change, but please don't try to argue that
>>> > its correct: the continued confusion of folk running into this is
>>> > evidence that confusion *is happening*. Treat that as evidence and
>>> > think about how to fix it going forward.
>>>
>>> Sorry, Rob, but you're just wrong here, and Nick is right. It's
>>> possible to improve Python 3, but not to "fix" it in this respect.
>>> The Python 3 solution is correct, the Python 2 approach is not.
>>> There's no way to avoid discontinuity and confusion here.
>>
>> I don't think there's any connection between the way 2.x confused text
>> strings and binary data (which certainly needed addressing) with the way
>> that 3.x returns a different type for byte_str[i] than it does for
>> byte_str[i:i+1]. I think it's the latter that's confusing to people.
>> There's no particular requirement for different types that's needed to
>> fix the byte/str problem.
>
> It's a mental model problem. People try to think of bytes as
> equivalent to 2.x str and that's just wrong, wrong, wrong. It's far
> closer to array.array('c'). Strings are basically *unique* in
> returning a length 1 instance of themselves for indexing operations.
> For every other sequence type, including tuples, lists and arrays,
> slicing returns a new instance of the same type, while indexing will
> typically return something different.
>
> Now, we definitely didn't *help* matters by keeping so many of the
> default behaviours of bytes() and bytearray() coupled to ASCII-encoded
> text, but that was a matter of practicality beating purity: there
> really *are* a lot of wire protocols out there that are ASCII based.
> In hindsight, perhaps we should have gone further in breaking things
> to try to make the point about the mental model shift more forcefully.
> (However, that idea carries with it its own problems).
For what it's worth, Erlang's approach to the subject is — in my
opinion — excellent:
binaries (whose literals are called "bit syntax" there) are quite
distinct from strings in both syntax and API, but you can put
chunks of strings within binaries (the bit syntax acts as a container,
in which you can put a literal or non-literal string). This
simultaneously impresses upon the user that binaries are *not* strings
and that they can still easily create binaries from strings.
___
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/archive%40mail-archive.com
Re: [Python-Dev] Python 3.x and bytes
On 2011-05-19, at 11:25 , Łukasz Langa wrote: > Wiadomość napisana przez Stefan Behnel w dniu 2011-05-19, o godz. 10:37: > >>> But why wouldn't "they" expect `b'de' + 1` to work as well in this case? If >>> a 1-byte bytes is equivalent to an integer, why not an arbitrary one as >>> well? >> >> The result of this must obviously be b"de1". > I hope you're joking. At best, the result should be b"de\x01". Actually, if `b'd'+1` returns `b'e'` an equivalent behavior should be that `b'de'+1` returns `b'df'`. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 3142: Add a "while" clause to generator expressions
On 22 Jan 2009, at 12:42 , Nick Coghlan wrote: Tino Wildenhain wrote: g=(i for i in xrange(1000))[2:5] g.next() # wrapper would now step 2 times w/o yield and 1 with yield 2 g.next() 3 g.next() 4 g.next() Traceback (most recent call last): File "", line 1, in StopIteration as expected - this could be included into itertools for now. Slicing of arbitrary iterators has been supported by itertools ever since the module was first added to the standard library. islice is pretty annoying in some aspects, though. Mainly because it doesn't accept kwargs and defaults to requiring the stop argument. So drop(iterable, n) has to be written islice(iterable, n, None) (and of course the naming isn't ideal), and you can't really use functools.partial since the iterator is the first argument (unless there's a way to partially apply only the tail args without kwargs). ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 3154 - pickle protocol 4
On 2011-08-12, at 12:58 , Antoine Pitrou wrote: > Current protocol versions export object sizes for various built-in types > (str, bytes) as 32-bit ints. This forbids serialization of large data > [1]_. New opcodes are required to support very large bytes and str > objects. How about changing object sizes to be 64b always? Too much overhead for the common case (which might be smaller pickled objects)? Or a slightly more devious scheme (e.g. tag-bit, untagged is 31b size, tagged is 63), which would not require adding opcodes for that? > Also, dedicated set support > could help remove the current impossibility of pickling > self-referential sets [2]_. Is there really no possibility of fix recursive pickling once and for all? Dedicated optcodes for resource consumption purposes (and to match those of other build-in types) is still a good idea, but being able to pickle arbitrary recursive structures would be even better would it not? And if specific (new) opcodes are required to handle recursive pickling correctly, that's the occasion. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] GIL removal question
On 2011-08-11, at 21:11 , Sturla Molden wrote: > > (b) another threading model (e.g. one interpreter per thread, as in Tcl, > Erlang, or .NET app domains). Nitpick: this is not correct re. erlang. While it is correct that it uses "another threading model" (one could even say "no threading model"), it's not a "one interpreter per thread" model at all: * Erlang uses "erlang processes", which are very cheap preempted *processes* (no shared memory). There have always been tens to thousands to millions of erlang processes per interpreter * A long time ago (before 2006 and the SMP VM, that was R11B) the erlang VM was single-threaded, so all those erlang processes ran in a single OS thread. To use multiple OS threads one had to create an erlang cluster (start multiple VMs and distribute spawned processes over those). However, this was already an m:n model, there were multiple erlang processes for each VM. * Since the introduction of the SMP VM, the erlang interpreter can create multiple *schedulers* (one per physical core by default), with each scheduler running in its own OS thread. In this model, there's a single interpreter and an m:n mapping of erlang processes to OS threads within that single interpreter. (interestingly, because -smp generates resource contention within the interpreter going back to pre-SMP by setting the number of schedulers per node to 1 can yield increased overall performances) ___ 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/archive%40mail-archive.com
Re: [Python-Dev] GIL removal question
On 2011-08-12, at 20:59 , Sturla Molden wrote: > Den 12.08.2011 18:51, skrev Xavier Morel: >> * Erlang uses "erlang processes", which are very cheap preempted *processes* >> (no shared memory). There have always been tens to thousands to millions of >> erlang processes per interpreter source contention within the interpreter >> going back to pre-SMP by setting the number of schedulers per node to 1 can >> yield increased overall performances) > > Technically, one can make threads behave like processes if they don't share > memory pages (though they will still share address space). Erlangs use of > 'process' instead of 'thread' does not mean an Erlang process has to be > implemented as an OS process. Of course not. I did not write anything implying that. > With one interpreter per thread, and a malloc that does not let threads share > memory pages (one heap per thread), Python could do the same. Again, my point is that Erlang does not work "with one interpreter per thread". Which was your claim. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 393 Summer of Code Project
On 2011-08-23, at 10:55 , Martin v. Löwis wrote: >> - “The UTF-8 decoding fast path for ASCII only characters was removed >> and replaced with a memcpy if the entire string is ASCII.” >> The fast path would still be useful for mostly-ASCII strings, which >> are extremely common (unless UTF-8 has become a no-op?). > > Is it really extremely common to have strings that are mostly-ASCII but > not completely ASCII? I would agree that pure ASCII strings are > extremely common. Mostly ascii is pretty common for western-european languages (French, for instance, is probably 90 to 95% ascii). It's also a risk in english, when the writer "correctly" spells foreign words (résumé and the like). ___ 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/archive%40mail-archive.com
Re: [Python-Dev] range objects in 3.x
On 2011-09-23, at 20:23 , Guido van Rossum wrote: > Also, Ethan, I hope you're familiar with the reason why there is no > range() support for floats currently? (Briefly, things like range(0.0, > 0.8, step=0.1) could include or exclude the end point depending on > rounding, which makes for troublesome semantics.) On the other hand, there could be a range for Decimal could there not? ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Heads up: Apple llvm gcc 4.2 miscompiles PEP 393
On 2011-09-28, at 13:24 , mar...@v.loewis.de wrote: > The gcc that Apple ships with the Lion SDK (not sure what Xcode version that > is) Xcode 4.1 > I'm not aware of a work-around in the code. My work-around is to use gcc-4.0, > which is still available on my system from an earlier Xcode installation > (in /Developer-3.2.6) Does Clang also fail to compile this? Clang was updated from 1.6 to 2.0 with Xcode 4, worth a try. Also, from your version listing it seems to be llvm-gcc (gcc frontend with llvm backend I think), is there no more straight gcc (with gcc frontend and backend)? FWIW, on 10.6 the default gcc is a straight 4.2 > gcc --version i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5664) There is an llvm-gcc 4.2 but it uses a slightly different revision of llvm > llvm-gcc --version i686-apple-darwin10-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2333.4) ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Heads up: Apple llvm gcc 4.2 miscompiles PEP 393
On 2011-09-28, at 19:49 , Martin v. Löwis wrote: > > Thanks for the advise - I didn't expect that Apple ships thhree compilers… Yeah I can understand that, they're in the middle of the transition but Clang is not quite there yet so... ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Hg tips
On 2011-09-29, at 12:07 , Victor Stinner wrote: > > * I disabled the merge GUI: I lose a lot of work because I'm unable to use a > GUI to do merge, I don't understand what are the 3 versions of the same file > (which one is the merged version!?) Generally none. By default, mercurial (and most similar tools) sets up LOCAL, BASE and OTHER. BASE is the last "common" state, LOCAL is the locally modified file and OTHER is the remotely modified file (which you're trying to merge). The behavior after that depends, mercurial has an OUTPUT pointer (for the result file), many tools just write the non-postfixed file with the merge result. And depending on your precise tool it can attempt to perform its own merge resolution before showing you the files, or just show you the three files provided and you set up your changes into BASE from LOCAL and OTHER. If you reach that state, it's becaused mercurial could not automatically process the merge so there's no merged version to display. Maybe thinking of it as a file with conflict markers split into three (one without the conflicting sections, one with only the first part of the sections and one with only the second part) would make it clearer? ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Hg tips
On 2011-09-29, at 12:50 , Victor Stinner wrote: > Le 29/09/2011 12:34, Xavier Morel a écrit : >> Generally none. By default, mercurial (and most similar tools) sets up >> LOCAL, BASE and OTHER. BASE is the... > > Sorry, but I'm unable to remember the meaning of LOCAL, BASE and OTHER. In > meld, I have to scroll to the end of the filename so see the filename suffix. > Anyway, my real problem was different: hg opened meld with the 3 versions, > but the BASE was already merged. I mean that hg chose for me what is the > right version, without letting me choose myself what is the good version, > because if I just close meld, I lose my local changes. I'd bet it's Meld doing that, though I have not checked (Araxis Merge does something similar, it has its own merge-algorithm which it tries to apply in case of 3-ways merge, trying to merge LOCAL and OTHER into base on its own). Look into Meld's configuration, it might be possible to disable that. (an other possibility would be that the wrong file pointers are send to Meld, so it gets e.g. twice the same file) > Because a merge is a new commit, I suppose that I can do something to get my > local changes back. But, well, I just prefer the "legacy" (?) merge flavor: > > <<<< local > ... > === > ... > >>> other > > It's easier for my brain because I just have 2 versions of the same code, not > 3! > > But it looks like some people are more confortable with 3 versions in a GUI, > because it is the default Mercurial behaviour (to open a GUI to solve > conflicts). > I'd be part of that camp, yes (though I'll use either depending on the exact situation, there are cases where seeing what both branches diverged from is very useful). I find having all three version makes it easier to correctly mix the two diverging versions, with /usr/bin/merge-style conflict markers it's harder to understand what both branches diverged from and hence how their changes fit into one another. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] order of Misc/ACKS
On 2011-11-12, at 10:24 , Georg Brandl wrote: > Am 12.11.2011 08:03, schrieb Stephen J. Turnbull: >> Eli Bendersky writes: >> >>> special locale. It makes me wonder whether it's possible to have a >>> contradiction in the ordering, i.e. have a set of names that just >>> can't be sorted in any order acceptable by everyone. >> >> Yes, it is. The examples were already given in this thread. The >> Han-using languages also have this problem, and Japanese is >> nondetermistic all by itself (there are kanji names which for >> historical reasons are pronounced in several different ways, and >> therefore cannot be placed in phonetic order without additional >> information). >> >> The sensible thing is to just sort in Unicode code point order, I >> think. > > The sensible thing is to accept that there is no solution, and to stop > worrying. The file could use the default collation order, that way it'd be incorrectly sorted for everybody. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Promoting Python 3 [was: PyPy 1.7 - widening the sweet spot]
On 2011-11-22, at 17:41 , Stephen J. Turnbull wrote: > Barry Warsaw writes: >> Hopefully, we're going to be making a dent in that in the next version of >> Ubuntu. > > This is still a big mess in Gentoo and MacPorts, though. MacPorts > hasn't done anything about ceating a transition infrastructure AFAICT. What kind of "transition infrastructure" would it need? It's definitely not going to replace the Apple-provided Python out of the box, so setting `python` to a python3 is not going to happen. It doesn't define a `python3`, so maybe that? Is there a document somewhere on what kind of things distros need for a transition plan? > Gentoo has its "eselect python set VERSION" stuff, but it's very > dangerous to set to a Python 3 version, as many things go permanently > wonky once you do. (So far I've been able to work around problems > this creates, but it's not much fun.) Macports provide `port select` which I believe has the same function (you need to install the `python_select` for it to be configured for the Python group), the syntax is port `select --set python $VERSION`: > python --version Python 2.6.1 > sudo port select --set python python32 Selecting 'python32' for 'python' succeeded. 'python32' is now active. > python --version Python 3.2.2 ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Promoting Python 3 [was: PyPy 1.7 - widening the sweet spot]
On 2011-11-23, at 04:51 , Stephen J. Turnbull wrote: > Xavier Morel writes: >> On 2011-11-22, at 17:41 , Stephen J. Turnbull wrote: >>> Barry Warsaw writes: > >>>> Hopefully, we're going to be making a dent in that in the next version of >>>> Ubuntu. > >>> This is still a big mess in Gentoo and MacPorts, though. MacPorts >>> hasn't done anything about ceating a transition infrastructure AFAICT. > >> What kind of "transition infrastructure" would it need? It's definitely >> not going to replace the Apple-provided Python out of the box, so >> setting `python` to a python3 is not going to happen. > > Sure, but many things do shadow Apple-provided software if you set > PATH=/opt/local/bin:$PATH. > Some I'm sure do, but "many" is more doubtful, and I have not seen any do that in the Python ecosystem: macports definitely won't install a bare (unversioned) `python` without the user asking. > I'm not sure what infrastructure is required, but I can't really see > MacPorts volunteers doing a 100% conversion the way that Ubuntu's paid > developers can. So there will be a long transition period, and I > wouldn't be surprised if multiple versions of Python 2 and multiple > versions of Python 3 will typically need to be simultaneously > available to different ports. That's already the case so it's not much of a change. > >> It doesn't define a `python3`, so maybe that? > A python3 symlink or script would help a little bit, but I don't think > that's necessary or sufficient, because ports already can and do > depend on Python x.y, not just Python x. Yes indeed, which is why I was wondering in the first place: other distributions are described as "fine" because they have separate Python2 and Python3 stacks, macports has a Python stack *per Python version* so why would it be more problematic when it should have even less conflicts? >> Macports provide `port select` which I believe has the same function >> (you need to install the `python_select` for it to be configured for >> the Python group), the syntax is port `select --set python $VERSION`: > > Sure. > > I haven't had the nerve to do this on MacPorts because "port" is such > a flaky thing (not so much port itself, but so many ports assume that > the port maintainer's local configuration is what others' systems use, > so I stay as vanilla as possible -- I rather doubt that many ports are > ready for Python 3, and I'm not willing to be a guinea pig). That is what I'd expect as well, I was just giving the corresponding tool to the gentoo version thereof. > The problem that I've run into with Gentoo is that *even when the > ebuild is prepared for Python 3* assumptions about the Python current > when the ebuild is installed/upgraded gets baked into the installation > (eg, print statement vs. print function), but some of the support > scripts just call "python" or something like that. OTOH, a few > ebuilds don't support Python 3 (or in a ebuild that nominally supports > Python 3, upstream does something perfectly reasonable for Python 2 > like assume that Latin-1 characters are acceptable in a ChangeLog, and > the ebuild maintainer doesn't test under Python 3 so it slips through) > so I have to do an eselect dance while emerging ... and in the > meantime things that expect Python 3 as the system Python break. > > So far, in Gentoo I've always been able to wiggle out of such problems > by doing the eselect dance two or three times with the ebuild that is > outdated, and then a couple of principal prerequisites or dependencies > at most. > > Given my experience with MacPorts I *very much* expect similar > issues with its ports. Yes I would as well, although: 1. A bare `python` call would always call into the Apple-provided Python, this has no reason to change so ports doing that should not be affected 2. Few ports should use Python (therefore assume things about Python) in their configuration/installation section (outside upstream's own assumptions): ports are tcl, not bash, so there shouldn't be too much reason to call Python from them ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Long term development external named branches and periodic merges from python
On 2011-11-24, at 21:55 , Nick Coghlan wrote: > I've never been able to get the Create Patch button to work reliably with > my BitBucket repo, so I still just run "hg diff -r default" locally and > upload the patch directly. Wouldn't it be simpler to just use MQ and upload the patch(es) from the series? Would be easier to keep in sync with the development tip too. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Deprecation policy
On 2011-11-28, at 10:30 , Raymond Hettinger wrote: > On Oct 24, 2011, at 5:58 AM, Ezio Melotti wrote: > How about we agree that actually removing things is usually bad for users. > It will be best if the core devs had a strong aversion to removal. > Instead, it is best to mark APIs as obsolete with a recommendation to use > something else instead. > There is rarely a need to actually remove support for something in the > standard library. The problem with "deprecating and not removing" (and worse, only informally deprecating by leaving a note in the documentation) is that you end up with zombie APIs: there are tons of tutorials & such on the web talking about them, they're not maintained, nobody really cares about them (but users who found them via Google) and they're all around harmful. It's the current state of many JDK 1.0 and 1.1 APIs and it's dreadful, most of them are more than a decade out of date, sometimes retrofitted for new interfaces (but APIs using them usually are *not* fixed, keeping them in their state of partial death), sometimes still *taught*, all of that because they're only informally deprecated (at best, sometimes not even that as other APIs still depend on them). It's bad for (language) users because they use outdated and partially unmaintained (at least in that it's not improved) APIs and it's bad for (language) maintainers in that once in a while they still have to dive into those things and fix bugs cropping up without the better understanding they have from the old APIs or the cleaner codebase they got from it. Not being too eager to kill APIs is good, but giving rise to this kind of living-dead APIs is no better in my opinion, even more so since Python has lost one of the few tools it had to manage them (as DeprecationWarning was silenced by default). Both choices are harmful to users, but in the long run I do think zombie APIs are worse. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Deprecation policy
On 2011-11-28, at 13:06 , Nick Coghlan wrote:
> On Mon, Nov 28, 2011 at 7:53 PM, Xavier Morel wrote:
>> Not being too eager to kill APIs is good, but giving rise to this kind of
>> living-dead APIs is no better in my opinion, even more so since Python has
>> lost one of the few tools it had to manage them (as DeprecationWarning was
>> silenced by default). Both choices are harmful to users, but in the long run
>> I do think zombie APIs are worse.
>
> But restricting ourselves to cleaning out such APIs every 10 years or
> so with a major version bump is also a potentially viable option.
>
> So long as the old APIs are fully tested and aren't actively *harmful*
> to creating reasonable code (e.g. optparse) then refraining from
> killing them before the (still hypothetical) 4.0 is reasonable.
Sure, the original proposal leaves the deprecation timelines as TBD and I hope
I did not give the impression of setting up a timeline (that was not the
intention). Ezio's original proposal could simply be implemented by having the
second step ("decide how long the deprecation should last") default to "the
next major release", I don't think that goes against his proposal, and in case
APIs are actively harmful (e.g. very hard to use correctly) the deprecation
timeline can be accelerated specifically for that case.
___
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/archive%40mail-archive.com
Re: [Python-Dev] Fixing the XML batteries
On 2011-12-09, at 09:41 , Martin v. Löwis wrote: >> a) The stdlib documentation should help users to choose the right tool >> right from the start. Instead of using the totally misleading wording >> that it uses now, it should be honest about the performance >> characteristics of MiniDOM and should actively suggest that those who >> don't know what to choose (or even *that* they can choose) should not >> use MiniDOM in the first place. > > I disagree. The right approach is not to document performance problems, > but to fix them. Even if performance problems "should not be documented", I think Stefan's point that users should be steered away from minidom and towards ET and cET is completely valid and worthy of support: the *only* advantage minidom has over ET is that it uses an interface familiar to Java users[0] (they are about the only people using actual W3C DOM, while the DOM exists in javascript I'd say most code out there actively tries to not touch it with anything less than a 10-foot library pole like jQuery). That interface is also, of course, absolutely dreadful. Minidom is inferior in interface flow and pythonicity, in terseness, in speed, in memory consumption (even more so using cElementTree, and that's not something which can be fixed unless minidom gets a C accelerator), etc… Even after fixing minidom (if anybody has the time and drive to commit to it), ET/cET should be preferred over it. And that's not even considering the ease of switching to lxml (if only for validators), which Stefan outlined. [0] not 100% true now that I think about it: handling mixed content is simpler in minidom as there is no .text/.tail duality and text nodes are nodes like every other, but I really can't think of an other reason to prefer minidom ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Fixing the XML batteries
On 2011-12-09, at 19:15 , Bill Janssen wrote: > I use ElementTree for parsing valid XML, but minidom for producing it. Could you expand on your reasons to use minidom for producing XML? ___ 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/archive%40mail-archive.com
Re: [Python-Dev] [PATCH] Adding braces to __future__
On 2011-12-09, at 21:26 , Cedric Sodhi wrote: > IF YOU THINK YOU MUST REPLY SOMETHING WITTY, ITERATE THAT THIS HAD BEEN > DISCUSSED BEFORE, REPLY THAT "IT'S SIMPLY NOT GO'NNA HAPPEN", THAT "WHO > DOESN'T LIKE IT IS FREE TO CHOOSE ANOTHER LANGUAGE" OR SOMETHING > SIMILAR, JUST DON'T. > > Otherwise, read on. > > I know very well that this topic has been discussed before. On forums. > Mailing lists. IRC. Blogs. From person to person, even. > > And I know equally well, from all those years experiencing > argument-turned-debates on the internet, how a (minor|major) fraction of > participants make up for their inability to lead a proper debate by > speaking the loudest of all, so that eventually quantity triumphs over > quality and logic. > > That ahead; I hope you can try not to fall in that category. Let instead > reason prevail over sentimentalism, mislead purism, elitism, and all > other sorts of isms which hinder advancement in the greater context. > > Python has surprised once already: The changes from 2 to 3 were not > downwards compatible because the core developers realized there is more > to a sustainable language than constantly patching it up until it comes > apart like the roman empire. > > Let's keep that spirit for a second and let us discuss braces, again, > with the clear goal of improving the language. > > End of disclaimer? > > End of disclaimer! > > Whitespace-Blocking (WSB) as opposed to Delimiter-Blocking (DB) has > reasons. What are those reasons? Well, primarily, it forces the > programmer to maintain well readable code. Then, some might argue, it is > quicker to type. > > Two reasons, but of what importance are they? And are they actually > reasons? > > You may guessed it from the questions themselves that I'm about to > question that. > > I don't intend to connote brazen implications, so let me spell out what > I just implied: I think anyone who thinks that exclusive WSB is a good > alternative or even preferable to DB is actually deluding themselves for > some personal version of one of those isms mentioned above. > > Let's examine these alleged advantages objectively one for one. But > before that, just to calm troubled waters a little, allow me bring > forward the conclusion: > > Absolutely no intentions to remowe WSB from Python. Although one might > have gotten that impression from the early paragraphs, no intentions to > break downwards compatibility, either. > > What Python needs is an alternative to WSB and can stay Python by still > offering WSB to all those who happen to like it. > > Readable code, is it really an advantage? > > Two linebreaks, just for the suspense, then: > > Of course it is. > > Forcing the programmer to write readable code, is that an advantage? No > suspense, the answer is Of course not. > > Python may have started off as the casual scripting language for casual > people. People, who may not even have known programming. And perhaps it > has made sense to force -- or shall we say motivate, since you can still > produce perfectly obfuscated code with Python -- them to write readably. > > But Python has matured and so has its clientele. Python does not become > a better language, neither for beginners nor for experienced programmers > who also frequently use Python these days, by patronizing them and > restricting them in their freedom. > > Readable code? Yes. Forcing people to write readable code by artificial > means? No. > > Practice is evidence for the mischief of this policy: Does the FOSS > community suffer from a notorious lack of proper indention or > readability of code? Of course we don't. > > I'm not a native speaker, but dict.cc tells me that what we call "mit > Kanonen auf Spatzen schießen" (firing cannons at sparrows) is called > breaking a fly on the wheel in English. > > I may lack the analogy for the fly on the wheel, which, if I'm not > mistaken, used to be a device for torture in the Middle Ages, but I can > tell you that the cannon ball which might have struck the sparrows, > coincidently caused havoc in the hinterlands. > > For the wide-spread and professional language Python is today, the idea > of forcing people to indent is misguided. These days, it may address a > neglible minority of absolute beginners who barely started programming > and would not listen to the simple advice of indenting properly, but on > the other hand it hurts/annoys/deters a great community of typical > programmers for whom DB has long become a de facto standard. > > For them, it's not a mere inconsistency without, for them, any apparent > reason. It's more than the inconvenience not being able to follow ones > long time practices, using the scripts one wrote for delimiters, the > shortcuts that are usually offered by editor, etc. > > It also brings about a whole class of new problems which may be > anticipated and prevent, yet bear a great potential for new, even > hard-to-find bugs (just in case anyone would respond that we had > ev
Re: [Python-Dev] [PATCH] Adding braces to __future__
On 2011-12-10, at 12:14 , francis wrote: > > (I thing that 'go' has some > autoformater or a standard way of formatting). `gofmt` yes, it simply reformats all the code to match the style decided by the core go team, it does not provide support formatting- independent edition. Think of it as pep8.py editing the code in place instead of just reporting the stuff it does not like. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Fixing the XML batteries
On 2011-12-11, at 23:03 , Martin v. Löwis wrote: > People are still using PyXML, despite it's not being maintained anymore. > Telling them to replace 4DOM with minidom is much more appropriate than > telling them to rewrite in ET. >From my understanding, Stefan's suggestion is mostly aimed at "new" python users trying to manipulate XML and not knowing what to use (yet). It's not about telling people to rewrite existing codebase (it's a good idea as well when possible, as far as I'm concerned, but it's a different issue). ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Fixing the XML batteries
On 2011-12-14, at 20:41 , Stefan Behnel wrote: > I meant: "lack of interest in improving them". It's clear from the discussion > that there are still users and that new code is still being written that uses > MiniDOM. However, I would argue that this cannot possibly be performance > critical code and that it only deals with somewhat small documents. I say > that because MiniDOM is evidently not suitable for large documents or > performance critical applications, so this is the only explanation I have why > the performance problems would not be obvious in the cases where it is still > being used. And if they do show, it appears to be much more likely that users > rewrite their code using ElementTree or lxml than that they try to fix > MiniDOM's performance issues. Could also be because "XML is slow (and sucks)" is part of the global consciousness at this point, and that minidom is slow and verbose doesn't surprise much. ___ 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/archive%40mail-archive.com
