[Python-Dev] Re: REPL output bug

[Xavier Morel]

> 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] Compact ordered set

[Xavier Morel]

> 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] Micro-optimizations by adding special-case bytecodes?

[Xavier Morel]

> On 2017-05-24, at 20:26 , Xavier Morel <python-...@masklinn.net> wrote:
> 
>> On 2017-05-24, at 20:07 , Ben Hoyt <benh...@gmail.com> 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

Re: [Python-Dev] Micro-optimizations by adding special-case bytecodes?

[Xavier Morel]

> 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] PyWeakref_GetObject() borrows its reference from... whom?

[Xavier Morel]

> 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] Bug in the DELETE statement in sqlite3 module

[Xavier Morel]

> 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] [python-committers] How are we merging forward from the Bitbucket 3.5 repo?

[Xavier Morel]

On 2015-08-16, at 16:08 , Guido van Rossum gu...@python.org 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] How far to go with user-friendliness

[Xavier Morel]

On 2015-07-14, at 14:39 , Nick Coghlan ncogh...@gmail.com wrote:

 On 14 July 2015 at 22:06, Dima Tisnek dim...@gmail.com 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] Improvements for Pathlib

[Xavier Morel]

On 2014-11-08, at 16:46 , Ionel Cristian Mărieș cont...@ionelmc.ro 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 rym...@gmail.com 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

[Xavier Morel]

On 2014-11-08, at 20:02 , Ionel Cristian Mărieș cont...@ionelmc.ro wrote:
 On Saturday, November 8, 2014, Xavier Morel python-...@masklinn.net 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 et...@stoneleaf.us 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] Critical bash vulnerability CVE-2014-6271 may affect Python on *n*x and OSX

[Xavier Morel]

On 2014-09-27, at 00:11 , Cameron Simpson c...@zip.com.au wrote:

 On 26Sep2014 13:16, Antoine Pitrou solip...@pitrou.net wrote:
 On Fri, 26 Sep 2014 01:10:53 -0700
 Hasan Diwan hasan.di...@gmail.com wrote:
 On 26 September 2014 00:28, Matěj Cepl mc...@cepl.eu 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] == on object tests identity in 3.x

[Xavier Morel]

On 2014-07-07, at 13:22 , Andreas Maier andreas.r.ma...@gmx.de 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] Negative timedelta strings

[Xavier Morel]

On 2014-04-02, at 15:04 , Skip Montanaro s...@pobox.com wrote:

 On Wed, Apr 2, 2014 at 7:52 AM, M.-A. Lemburg m...@egenix.com 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)
 mx.DateTime.DateTime object for '2014-03-28 00:00:00.00' at 1eda8c8
 d = Date(2014, 1, 31)
 d + RelativeDateTime(months=+1)
 mx.DateTime.DateTime object for '2014-03-03 00:00:00.00' at 1eda870
 
 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] Negative timedelta strings

[Xavier Morel]

On 2014-03-28, at 17:19 , Skip Montanaro s...@pobox.com 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] Reference cycles in Exception.__traceback__

[Xavier Morel]

On 2014-03-06, at 16:52 , Antoine Pitrou solip...@pitrou.net 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__

[Xavier Morel]

On 2014-03-06, at 19:32 , Guido van Rossum gu...@python.org 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] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5

[Xavier Morel]

On 2014-01-06, at 14:44 , Antoine Pitrou solip...@pitrou.net 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] Bug? http.client assumes iso-8859-1 encoding of HTTP headers

[Xavier Morel]

On 2014-01-04, at 17:24 , Chris Angelico ros...@gmail.com wrote:

 On Sun, Jan 5, 2014 at 2:36 AM, Hugo G. Fierro h...@gfierro.com 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] PEP 428 - pathlib - ready for approval

[Xavier Morel]

On 2013-11-20, at 17:09 , Guido van Rossum gu...@python.org wrote:

 On Wed, Nov 20, 2013 at 6:01 AM, Ethan Furman et...@stoneleaf.us 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] Context management patterns

[Xavier Morel]

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] On suppress()'s trail blazing (was Re: cpython: Rename contextlib.ignored() to contextlib.ignore())

[Xavier Morel]

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())

[Xavier Morel]

On 2013-10-17, at 20:55 , Oscar Benjamin wrote:
 On 17 October 2013 19:40, Xavier Morel python-...@masklinn.net 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())

[Xavier Morel]

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] Optimization

[Xavier Morel]

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] summing integer and class

[Xavier Morel]

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 module
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] Why not support user defined operator overloading ?

[Xavier Morel]

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
left shift
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] Best practice for documentation for std lib

[Xavier Morel]

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

[Xavier Morel]

 On 22 Sep 2013, at 05:25, Benjamin Peterson benja...@python.org 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

[Xavier Morel]

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] Use an empty def as a lambda

[Xavier Morel]

On 2013-09-19, at 23:17 , Nick Coghlan wrote:

 On 20 Sep 2013 07:04, Joe Pinsonault joe.pinsona...@gmail.com 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] DTRACE support

[Xavier Morel]

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 j...@jcea.es 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] DTRACE support

[Xavier Morel]

On 2013-09-06, at 19:05 , Antoine Pitrou wrote:

 On Fri, 06 Sep 2013 18:14:26 +0200
 Jesus Cea j...@jcea.es 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] PEP 435: pickling enums created with the functional API

[Xavier Morel]

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] Why can't I encode/decode base64 without importing a module?

[Xavier Morel]

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] Semantics of __int__(), __index__()

[Xavier Morel]

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__()

[Xavier Morel]

On 2013-04-04, at 17:01 , Chris Angelico wrote:

 On Fri, Apr 5, 2013 at 1:59 AM, Guido van Rossum gu...@python.org wrote:
 On Thu, Apr 4, 2013 at 7:47 AM, Chris Angelico ros...@gmail.com 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] Semantics of __int__(), __index__()

[Xavier Morel]

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
class 'int' = class '__main__.my_int' ? False
class 'float' = class '__main__.my_float' ? False
class 'complex' = class 'complex' ? True
class 'bytes' = class '__main__.my_bytes' ? False
class 'str' = class '__main__.my_str' ? 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] IDLE in the stdlib

[Xavier Morel]

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

[Xavier Morel]

On 2013-03-20, at 20:59 , Brian Curtin wrote:

 On Wed, Mar 20, 2013 at 2:51 PM, Xavier Morel python-...@masklinn.net 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

[Xavier Morel]

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] Difference in RE between 3.2 and 3.3 (or Aaron Swartz memorial)

[Xavier Morel]

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] cffi in stdlib

[Xavier Morel]

On 2013-02-27, at 14:31 , Antoine Pitrou wrote:

 Le Wed, 27 Feb 2013 12:15:05 +1300,
 Greg Ewing greg.ew...@canterbury.ac.nz 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] Usage of += on strings in loops in stdlib

[Xavier Morel]

On 2013-02-13, at 12:37 , Steven D'Aprano wrote:
 
# even less obvious than sum
map(operator.add, array)

That one does not work, it'll try to call the binary `add` with each
item of the array when the map iterator is reified, erroring out.

functools.reduce(operator.add, array, '')

would work though, it's an other way to spell `sum` without the
string prohibition.
___
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] Marking GC details as CPython-only

[Xavier Morel]

On 2013-02-13, at 19:48 , Maciej Fijalkowski wrote:

 Hi
 
 I've tried (and failed) to find what GC details (especially finalizer
 semantics) are CPython only and which ones are not. The best I could
 find was the documentation of __del__ here:
 http://docs.python.org/2/reference/datamodel.html
 
 Things were pypy differs:
 
 * finalizers in pypy will be called only once, even if the object is
 resurrected. I'm not sure if this is detail or we're just plain
 incompatible.
 
 * pypy breaks cycles and runs finalizers in random order (but
 topologically correct), hence gc.garbage is always empty. I *think*
 this part is really just an implementation detail
 
 * we're discussing right now about running multiple finalizers. We
 want to run them in order, but if there is a link a - b and a becomes
 unreachable, we want to reserve the right to call finalizer a then
 finalizer b, even if a.__del__ resurrects a. What do you think?
 
 Overall, the __del__ is baaad.
 
 Cheers,
 fijal

There may be one more, although I'm not sure whether it's a GC artifact
or something completely unspecified: if a context manager is part of a
suspended stack (because it's in a generator) when the program
terminates, cpython will run __exit__ but pypy will not

--
# -*- encoding: utf-8 -*-
class C(object):
def __enter__(self):
print (entering)
def __exit__(self, *args):
print (exiting)

def gen():
with C():
yield

r = gen()
next(r)
--
$ python2 test.py
entering
exiting
$ python3 test.py
entering
exiting
$ pypy test.py
entering
$
--

___
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] Usage of += on strings in loops in stdlib

[Xavier Morel]

On 2013-02-12, at 22:40 , Ned Batchelder wrote:
 But the only reason .join() is a Python idiom in the first place is because 
 it was the fast way to do what everyone initially coded as s +=    
 Just because we all learned a long time ago that joining was the fast way to 
 build a string doesn't mean that .join() is the clean idiomatic way to do 
 it.

Well no, str.join is the idiomatic way to do it because it is:

 idiomatic |ˌidēəˈmatik|
 adjective
 1 using, containing, or denoting expressions that are natural to a native 
 speaker 

or would you argue that the natural way for weathered python developers
to concatenate string is to *not* use str.join?

Of course usually idioms have original reasons for being, reasons which
are sometimes long gone (not unlike religious mandates or prohibitions).

For Python, ignoring the refcounting hack (which is not only cpython
specific but *current* cpython specific *and* doesn't apply to all
cases) that reason still exist: python's strings are formally immutable
bytestrings, and repeated concatenation of immutable bytestrings is
quadratic.

Thus str.join is idiomatic, and although it's possible (if difficult) to
change the idiom straight string concatenation would make a terrible new
idiom as it will behave either unreliably (current CPython) or simply
terribly (every other Python implementation).

No?
___
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 do we allow this syntax?

[Xavier Morel]

On 2013-02-08, at 16:39 , Chris Withers wrote:

 Hi All,
 
 Just had a bit of an embarrassing incident in some code where I did:
 
 sometotal =+ somevalue
 
 I'm curious why this syntax is allowed? I'm sure there are good reasons, but 
 thought I'd ask…

sometotal = (expression) is valid syntax, and +value is valid syntax.

Thus what you wrote is perfectly normal syntax, it's the assignment of a
pos'd value, badly formatted. pep8.py will warn against it (it'll
complain that the whitespace around `+` is wonky). But I see no
justification for disallowing this, anymore than for disallowing the
rougly equivalent (and just as error-prone) `sometotal = -somevalue`.
___
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 do we allow this syntax?

[Xavier Morel]

On 2013-02-08, at 18:45 , Chris Withers wrote:

 On 08/02/2013 16:17, Oscar Benjamin wrote:
 Decimal.__pos__ uses it to return a Decimal instance that has the
 default precision of the current Decimal context:
 
 from decimal import Decimal
 d = Decimal('0.33')
 d
 Decimal('0.33')
 +d
 Decimal('0.')
 
 That's the answer I was hoping wouldn't be coming...
 
 Oh well, guess I'll have to improve on my sloppy typing.

Or just run flake8 (with a bit of configuration to disable the annoying stuff).
___
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] Emacs users: hg-tools-grep

[Xavier Morel]

On 2012-12-12, at 15:12 , Ross Lagerwall wrote:

 On Wed, Dec 12, 2012 at 01:27:21PM +0200, Petri Lehtinen wrote:
 Brandon W Maister wrote:
 (defconst git-tools-grep-command
  git ls-files -z | xargs -0 grep -In %s
  The command used for grepping files using git. See `git-tools-grep'.)
 
 What's wrong with git grep?
 
 Or hg grep, for that matter?

hg grep searches the history, not the working copy. *-tools-grep only
searches the working copy but automatically filters files to only search
in files under version control.

Which as far as I know is indeed what git-grep does already.
___
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] logging and rotation

[Xavier Morel]

On 2012-11-25, at 18:02 , Oleg Broytman wrote:
 On Sun, Nov 25, 2012 at 01:14:11PM +0100, Matthias Bernt matat...@gmx.de 
 wrote:
 I'm using the logging module and write my log messages via the FileHandler.
 I just realized that using an external log rotation mechanism does not
 work. That is, new messages are not added to the file after
 rotation.
 
   An external log rotation mechanism ought to send a signal to the
 application and the application ought to close and reopen logs. That is,
 this is an application-level problem, not logging module-level.

I don't know that FileHandler officially supports reopening its
underlying file. On the other hand, WatchedFileHandler[0] does exactly
that and is specifically advertised for use with external log rotators:

 WatchedFileHandler […] watches the file it is logging to. If the file
 changes, it is closed and reopened using the file name.

 A file change can happen because of usage of programs such as newsyslog
 and logrotate which perform log file rotation. […] If the file has changed,
 the old file stream is closed, and the file opened to get a new stream.

[0] http://docs.python.org/2/library/logging.handlers.html#watchedfilehandler
___
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] type vs. class terminology

[Xavier Morel]

On 2012-11-26, at 07:54 , Nick Coghlan wrote:

 On Mon, Nov 26, 2012 at 3:01 PM, Chris Jerdonek 
 chris.jerdo...@gmail.comwrote:
 
 I would like to know when we should use class in the Python 3
 documentation, and when we should use type.  Are these terms
 synonymous in Python 3, and do we have a preference for which to use
 and when?
 
 I'm sure this has been discussed before.  But if this terminology
 issue has already been resolved, the resolution doesn't seem to be
 reflected in the docs.  For example, the glossary entries for type and
 class don't reference each other.
 
 
 The historical distinction between builtin types and user-defined
 classes predates new-style classes (which unified the type system) and
 Python 3 (which eliminated the instance type that was provided to
 preserve the legacy user-defined class semantics in Python 2). The glossary
 unfortunately still reflects this distinction, which no longer exists in
 Python 3.
 
 A slightly more useful distinction would be if type was used consistently
 to refer to type(x), while class was used to refer to x.__class__, since
 they can and do differ in the case of proxy types (like weakref.proxy).
 However, it's probably too late for that kind of fine distinction - in
 reality, the two terms are now used pretty much interchangeably.

There's an other possible usage which is between `type` subclasses and
`type` instances (`type` essentially becomes a synonym for `metaclass`),
I've seen that kind of usage at least once in the docs:
http://docs.python.org/2/c-api/object.html#PyObject_IsInstance

 If cls is a type object rather than a class object, PyObject_IsInstance()
 returns 1 if inst is of type cls.
___
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] performance of {} versus dict()

[Xavier Morel]

On 2012-11-14, at 17:42 , Richard Oudkerk wrote:

 On 14/11/2012 4:23pm, Serhiy Storchaka wrote:
 PEP 8 recommends:
 
 a_dict = dict(
 x=1,
 y=2,
 z=3,
 ...
 )
 
 and
 
 a_dict = {
 'x': 1,
 'y': 2,
 'z': 3,
 ...
 }
 
 In which section?  I can't see such a recommendation.

Whitespace in Expressions and Statements  Other Recommendations

3rd bullet:

—
Don't use spaces around the = sign when used to indicate a keyword argument or 
a default parameter value.

Yes:

def complex(real, imag=0.0):
return magic(r=real, i=imag)

No:

def complex(real, imag = 0.0):
return magic(r = real, i = imag)
—

___
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] performance of {} versus dict()

[Xavier Morel]

On 2012-11-14, at 18:08 , Mark Adam wrote:
 
 That's not a recommendation to use the **kwargs style.

And nobody said it was. It's a recommendation to not put spaces around
the equals sign when using keyword arguments which is the correction
Serhiy applied to the original code (along with adding a space after the
colon in the literal dict, also a PEP8 recommendation).
___
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] performance of {} versus dict()

[Xavier Morel]

On 2012-11-14, at 18:10 , Mark Adam wrote:
 
 Try the canonical {'x':1}.  Only dict allows the special
 initialization above.  Other collections require an iterable.

Other collections don't have a choice, because it would often be
ambiguous. Dicts do not have that issue.

  I'm guessing
 **kwargs initialization was only used because it is so simple to
 implement, but that's not necessarily a heuristic for good language design.

In this case it very much is, it permits easily merging two dicts in a
single expression or cloning-with-replacement. It also mirrors the
signature of dict.update which I think is a Good Thing.
___
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] performance of {} versus dict()

[Xavier Morel]

On 2012-11-14, at 19:54 , Mark Adam wrote:
 
 Merging of two dicts is done with dict.update.

No, dict.update merges one dict (or two) into a third one.

 How do you do it on
 initialization?  This doesn't make sense.

dict(d1, **d2)
___
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] performance of {} versus dict()

[Xavier Morel]

On 2012-11-14, at 21:53 , Mark Adam wrote:

 On Wed, Nov 14, 2012 at 1:37 PM, Xavier Morel catch-...@masklinn.net wrote:
 On 2012-11-14, at 19:54 , Mark Adam wrote:
 
 Merging of two dicts is done with dict.update.
 
 No, dict.update merges one dict (or two) into a third one.
 
 No.  I think you need to read the docs.

I know what the docs say. dict.update requires an existing dict and (as
mutator methods usually do in Python) doesn't return anything. Thus it
merges a dict (or two) into a third one (the subject of the call).

 How do you do it on
 initialization?  This doesn't make sense.
 
 dict(d1, **d2)
 
 That's not valid syntax is it?

Of course it is, why would it not be?
___
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] performance of {} versus dict(), de fmd(**kw): return kw trumps all ; -)

[Xavier Morel]

On 2012-11-14, at 23:43 , Chris Withers wrote:

 On 14/11/2012 22:37, Chris Withers wrote:
 On 14/11/2012 10:11, mar...@v.loewis.de wrote:
 def xdict(**kwds):
   return kwds
 
 Hah, good call, this trumps both of the other options:
 
 $ python2.7 -m timeit -n 100 -r 5 -v
 {'a':1,'b':2,'c':3,'d':4,'e':5,'f':6,'g':7}
 raw times: 1.45 1.45 1.44 1.45 1.45
 100 loops, best of 5: 1.44 usec per loop
 $ python2.6 -m timeit -n 100 -r 5 -v
 'dict(a=1,b=2,c=3,d=4,e=5,f=6,g=7)'
 raw times: 2.37 2.36 2.36 2.37 2.37
 100 loops, best of 5: 2.36 usec per loop$ python2.6 -m timeit -n
 100 -r 5 -v 'def md(**kw): return kw; md(a=1,b=2,c=3,d=4,e=5,f=6,g=7)'
 raw times: 0.548 0.533 0.55 0.577 0.539
 100 loops, best of 5: 0.533 usec per loop
 
 Before anyone shoots me, yes, wrong python for two of them:
 
 $ python2.7 -m timeit -n 100 -r 5 -v 
 {'a':1,'b':2,'c':3,'d':4,'e':5,'f':6,'g':7}
 raw times: 1.49 1.49 1.5 1.49 1.48
 100 loops, best of 5: 1.48 usec per loop
 
 $ python2.7 -m timeit -n 100 -r 5 -v 'dict(a=1,b=2,c=3,d=4,e=5,f=6,g=7)'
 raw times: 2.35 2.36 2.41 2.42 2.35
 100 loops, best of 5: 2.35 usec per loop
 
 $ python2.7 -m timeit -n 100 -r 5 -v 'def md(**kw): return kw; 
 md(a=1,b=2,c=3,d=4,e=5,f=6,g=7)'
 raw times: 0.507 0.515 0.516 0.529 0.524
 100 loops, best of 5: 0.507 usec per loop

The last one is kind-of weird, it seems to be greatly advantaged by the local 
lookup:

 python2.7 -m timeit -n 100 -r 5 -v 
 {'a':1,'b':2,'c':3,'d':4,'e':5,'f':6,'g':7} 
raw times: 0.676 0.683 0.682 0.698 0.691
100 loops, best of 5: 0.676 usec per loop
 python2.7 -m timeit -n 100 -r 5 -v 'dict(a=1,b=2,c=3,d=4,e=5,f=6,g=7)'

raw times: 1.64 1.66 1.4 1.44 1.44
100 loops, best of 5: 1.4 usec per loop
 python2.7 -m timeit -n 100 -r 5 -v 'def md(**kw): return kw; 
 md(a=1,b=2,c=3,d=4,e=5,f=6,g=7)'
raw times: 0.188 0.203 0.201 0.195 0.202
100 loops, best of 5: 0.188 usec per loop
 python2.7 -m timeit -n 100 -r 5 -v -s 'def md(**kw): return kw' 
 'md(a=1,b=2,c=3,d=4,e=5,f=6,g=7)'
raw times: 0.871 0.864 0.863 0.889 0.871
100 loops, best of 5: 0.863 usec per loop

___
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] ctypes is not an acceptable implementation strategy for modules in the standard library?

[Xavier Morel]

On 2012-11-05, at 10:32 , Ronald Oussoren wrote:
 My arguments for ctypes:
 1. doesn't require compilation
 2. easier to maintain (no C/toolchain knowledge/ownership needed)
 3. pure Python is impossible to exploit (unlike pure C)
 
 That's not not quite true, python code that uses ctypes can still cause 
 buffer overflows and the like

Such as segfaulting the interpreter. I seem to reliably segfault
everything every time I try to use ctypes.
___
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] Sign of bytes

[Xavier Morel]

On 2012-10-31, at 18:44 , anatoly techtonik wrote:
 I wonder why Python uses signed chars for bytes
 http://docs.python.org/2/library/ctypes.html#ctypes.c_byte

That's not Python, that's ctypes. struct[0] has no bytes it uses
char for everything.

If I had to guess, it would be because char is already an unsigned
char in ctypes, signed_char is way too long, schar looks like dog
vomit and there was no point in aliasing byte to char. Which left
byte free for signed char.

[0] http://docs.python.org/2/library/struct.html#format-characters
___
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] [BUG] Trailing spaces in pretty-printed JSON

[Xavier Morel]

On 2012-10-13, at 08:40 , Leo wrote:

 Use this script on a json file and observe all the trailing spaces
 generated. (screenshot attached.)

1. Why didn't you report that on the tracker?
2. Why are you rewriting json.tool?
___
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] Stdlib and timezones, again

[Xavier Morel]

On 2012-10-01, at 17:32 , Terry Reedy wrote:

 On 10/1/2012 10:06 AM, Lennart Regebro wrote:
 
 Actually, that's not a bad idea. My original idea was to warn if it
 *was* outdated, but since there is no way to check that, I scratched
 that idea.
 
 Is there really no way to get a 'last updated' time from the site where the 
 database is kept? If not, perhaps we should provide one with a daily job (on 
 pypi?) that downloads and compares.

There are several: there's a message on a dedicated mailing list and
there are HTTP, FTP and rsync repositories with both all releases and a
latest archive for both tzdata and tzcode. The HTTP repositories seems
to handle time-based conditional requests correctly (an
If-Modified-Since with the date of the latest release or later will
result in a 304 response, earlier will result in a 200)

The HTTP URIs are 
https://www.iana.org/time-zones/repository/tzdata-latest.tar.gz
and https://www.iana.org/time-zones/repository/tzcode-latest.tar.gz

For some reason, IANA does not seem to publish a feed.
___
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] Stdlib and timezones, again

[Xavier Morel]

On 2012-09-30, at 15:15 , Antoine Pitrou wrote:

 On Sun, 30 Sep 2012 15:10:06 +0200
 Dirkjan Ochtman dirk...@ochtman.nl wrote:
 On Sun, Sep 30, 2012 at 3:03 PM, Antoine Pitrou solip...@pitrou.net wrote:
 Can't we simply include the Olson database in Windows installers?
 
 We probably can, but the problem is that it's updated quite often (for
 example, in 2011, there were about 14 releases; in 2009, there were
 21). So you'd want to have a mechanism to override the data that is
 included in the stdlib.
 
 Probably, but for most purposes I would guess a 2-year old database is
 still good enough? After all, you don't see many people complaining
 about the outdated Unicode database that is hard-wired in past Pythons.

But at worst, an outdated unicode database will be missing data right?

Doesn't an outdated timezone db have the risk of returning *incorrect* data?
___
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] 3.3 str timings

[Xavier Morel]

On 21 août 2012, at 19:25, Steven D'Aprano st...@pearwood.info wrote:
 On 21/08/12 23:04, Victor Stinner wrote:
 
 I don't like the timeit module for micro benchmarks, it is really
 unstable (default settings are not written for micro benchmarks).
 [...]
 I wrote my own benchmark tool, based on timeit, to have more stable
 results on micro benchmarks:
 https://bitbucket.org/haypo/misc/src/tip/python/benchmark.py
 
 I am surprised, because the whole purpose of timeit is to time micro
 code snippets.

And when invoked from the command-line, it is already time-based: unless -n is 
specified, python guesstimates the number of iterations to be a power of 10 
resulting in at least 0.2s per test (the repeat defaults to 3 though)

As a side-note, every time I use timeit programmatically, it annoys me that 
this behavior is not available and has to be implemented manually. 

 If it is as unstable as you suggest, and if you have an alternative
 which is more stable and accurate, I would love to see it in the
 standard library.
___
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] Introduction

[Xavier Morel]

On 2012-08-02, at 09:28 , Shanth Kumar wrote:

 Hi I am Shanthkumar from Bangalore, India, working for a software firm.
 Good to see the mailing group, as i am new to python curious to ask you
 people couple of queireis.

I fear that is very likely the wrong mailing list for that: python-dev
is about the development of the CPython runtime and the language
itself, not so much about learning it and developing in it.

You probably want python-list
(http://mail.python.org/mailman/listinfo/python-list) or tutor
(http://mail.python.org/mailman/listinfo/tutor), or your local user
group's mailing list (http://mail.python.org/mailman/listinfo/bangpypers)
___
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] backporting stdlib 2.7.x from pypy to cpython

[Xavier Morel]

On 2012-06-08, at 20:29 , Brett Cannon wrote:

 On Fri, Jun 8, 2012 at 2:21 PM, fwierzbi...@gmail.com fwierzbi...@gmail.com
 wrote:
 
 On Fri, Jun 8, 2012 at 10:59 AM, Brett Cannon br...@python.org wrote:
 R. David already replied to this, but just to reiterate: tests can always
 get updated, and code that fixes a bug (and leaving a file open can be
 considered a bug) can also go in. It's just stuff like code refactoring,
 speed improvements, etc. that can't go into Python 2.7 at this point.
 Thanks for the clarification!
 
 If/until the stdlib is made into its own repo, should the various VMs
 consider keeping a common Python 2.7 repo that contains nothing but the
 stdlib (or at least just modifications to those) so they can modify in
 ways
 that CPython can't accept because of compatibility policy? You could
 keep it
 on hg.python.org (or wherever) and then all push to it. This might also
 be a
 good way to share Python implementations of extension modules for Python
 2.7
 instead of everyone maintaining there own for the next few years
 (although I
 think those modules should go into the stdlib directly for Python 3 as
 well). Basically this could be a test to see if communication and
 collaboration will be high enough among the other VMs to bother with
 breaking out the actual stdlib into its own repo or if it would just be a
 big waste of time.
 I'd be up for trying this. I don't think it's easy to fork a
 subdirectory of CPython though - right now I just keep an unchanged
 copy of the 2.7 LIb in our repo (PyPy does the same, at least the last
 time I checked).
 
 
 Looks like hg doesn't have support yet:
 http://stackoverflow.com/questions/920355/how-do-i-clone-a-sub-folder-of-a-repository-in-mercurial
 

Using that would mean commits in the externalized stdlib would go into
the Python 2.7 repo, which I assume is *not* desirable.

A better-fitting path of action would be a hg - hg convert using a
filemap, as the first comment in your link shows. That would create a
full copy (with history replay) of the standard library, in a brand new
repository.

Then *that* could be used by 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] Possible rough edges in Python 3 metaclasses (was Re: Language reference updated for metaclasses)

[Xavier Morel]

On 5 juin 2012, at 14:24, Nick Coghlan ncogh...@gmail.com wrote:

 On Tue, Jun 5, 2012 at 8:25 PM, Nick Coghlan ncogh...@gmail.com wrote:
 On Tue, Jun 5, 2012 at 7:11 PM, Michael Foord fuzzy...@voidspace.org.uk 
 wrote:
 
 On 5 Jun 2012, at 08:53, Nick Coghlan wrote:
 
 [snip...]
 
 Now, one minor annoyance with current class decorators is that they're
 *not* inherited. This is sometimes what you want, but sometimes you
 would prefer to automatically decorate all subclasses as well.
 Currently, that means writing a custom metaclass to automatically
 apply the decorators. This has all the problems you have noted with
 composability.
 
 It seems then, that a potentially clean solution may be found by
 adding a *dynamic* class decoration hook. As a quick sketch of such a
 scheme, add the following step to the class creation process (between
 the current class creation process, but before the execution of
 lexical decorators):
 
for mro_cls in cls.mro():
decorators = mro_cls.__dict__.get(__decorators__, ())
for deco in reversed(decorators):
cls = deco(cls)
 
 Would such a dynamic class decoration hook meet your use case? Such a
 hook has use cases (specifically involving decorator inheritance) that
 *don't* require the use of sys._getframes(), so is far more likely to
 achieve the necessary level of consensus.
 
 As a specific example, the unittest module could use it to provide
 test parameterisation without needing a custom metaclass.
 
 
 Heh, you're effectively restoring the old Python 2 metaclass machinery with 
 a slightly-less-esoteric mechanism. That aside I really like it.
 
 Yup, writing a PEP now - I'm mostly interested in the inheritance
 aspects, but providing PJE with a way to get the effect he wants
 without monkeypatching undocumented builtins at runtime and
 effectively forking CPython's runtime behaviour is a useful bonus.
 
 Metaclasses *do* have a problem with composition and lexical
 decorators don't play nicely with inheritance, but a dynamic decorator
 system modelled to some degree on the old __metaclass__ mechanics
 could fill the gap nicely.
 
 PEP written and posted: http://www.python.org/dev/peps/pep-0422/
 More toy examples here:
 https://bitbucket.org/ncoghlan/misc/src/default/pep422.py
 

Does it really make sense to meld decorators and inheritance so? With this, 
class decorators become way more than mere decorators and start straying 
quite far away from their function-based counterparts (which are not 
inherited when overriding methods but are statically applied instead)
___
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] c/ElementTree XML serialisation

[Xavier Morel]

On 2012-05-09, at 01:41 , Alex Leach wrote:
 
 True. I might not need the CDATA tag to wrap the javascript then, but I still 
 need  and  symbols. I have no idea how to write a loop in javascript 
 without 
 one.

Erm… you have them? What do you think `lt;` and `gt;` are?

As to writing a loop in javascript without  and , == and != generally
work rather well, as does Array.prototype.forEach[0]

[0] 
https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Array/forEach
___
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] Add a frozendict builtin type

[Xavier Morel]

On 2012-02-27, at 19:53 , Victor Stinner wrote:

 Rationale
 =
 
 A frozendict type is a common request from users and there are various
 implementations. There are two main Python implementations:
 
 * blacklist: frozendict inheriting from dict and overriding methods
 to raise an exception when trying to modify the frozendict
 * whitelist: frozendict not inheriting from dict and only implement
 some dict methods, or implement all dict methods but raise exceptions
 when trying to modify the frozendict
 
 The blacklist implementation has a major issue: it is still possible
 to call write methods of the dict class (e.g. dict.set(my_frozendict,
 key, value)).
 
 The whitelist implementation has an issue: frozendict and dict are not
 compatible, dict is not a subclass of frozendict (and frozendict is
 not a subclass of dict).

This may be an issue at the C level (I'm not sure), but since this would
be a Python 3-only collection, user code (in Python) should/would
generally be using abstract base classes, so type-checking would not
be an issue (as in Python code performing `isinstance(a, dict)` checks
naturally failing on `frozendict`)

Plus `frozenset` does not inherit from `set`, it's a whitelist
reimplementation and I've never known anybody to care. So there's
that precedent. And of course there's no inheritance relationship
between lists and tuples.

 * frozendict has not the following methods: clear, __delitem__, pop,
 popitem, setdefault, __setitem__ and update. As tuple/frozenset has
 less methods than list/set.

It'd probably be simpler to define that frozendict is a Mapping (where
dict is a MutableMapping). And that's clearer.

 * Make dict inherits from frozendict

Isn't that the other way around from the statement above? Not that I'd
have an issue with it, it's much cleaner, but there's little gained by
doing so since `isinstance(a, dict)` will still fail if `a` is a
frozendict.

 * Add a frozendict abstract base class to collections?

Why? There's no `dict` ABC, and there are already a Mapping and a
MutableMapping ABC which fit the bill no?
___
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] hash randomization in 3.3

[Xavier Morel]

On 2012-02-21, at 21:24 , Brett Cannon wrote:
 On Tue, Feb 21, 2012 at 15:05, Barry Warsaw ba...@python.org wrote:
 
 On Feb 21, 2012, at 02:58 PM, Benjamin Peterson wrote:
 
 2012/2/21 Antoine Pitrou solip...@pitrou.net:
 
 Hello,
 
 Shouldn't it be enabled by default in 3.3?
 
 Yes.
 
 Should you be able to disable it?
 
 No, but you should be able to provide a seed.
 
 I think that's inviting trouble if you can provide the seed. It leads to a
 false sense of security in that providing some seed secures them instead of
 just making it a tad harder for the attack.

I might have misunderstood something, but wouldn't providing a seed always 
make it *easier* for the attacker, compared to a randomized hash?

___
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] folding cElementTree behind ElementTree in 3.3

[Xavier Morel]

On 2012-02-20, at 12:36 , Eli Bendersky wrote:
 On Mon, Feb 20, 2012 at 01:12, Martin v. Löwis mar...@v.loewis.de wrote:
 
 The change of backing ElementTree by cElementTree has already been
 implemented in the default branch (3.3) by Florent Xicluna with careful
 review from me and others. etree has an extensive (albeit a bit clumsy)
 set of tests which keep passing successfully after the change.
 
 I just noticed an incompatible change: xml.etree.ElementTree.Element
 used to be a type, but is now a function.
 
 
 Yes, this is a result of an incompatibility between the Python and C
 implementations of ElementTree. Since these have now been merged by
 default, one or the other had to be kept and the choice of cElementTree
 appeared to be sensible since this is what most people are expected to use
 in 2.7 and 3.2 anyway. I have an issue open for converting some function
 constructors into classes. Perhaps Element should also have this fate.

I'm not sure that's much of an issue, Element (and most of the top-level
utility constructors) are documented as being frontend interfaces with
no specific type of their own, and indeed they are simply functions in
lxml, just as they are in cElementTree.

Others will probably disagree, but as far as I am concerned these can stay
functions, avoid issues when switching to lxml or between ElementTree and
lxml (from one project to the next).
___
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] folding cElementTree behind ElementTree in 3.3

[Xavier Morel]

On 2012-02-14, at 08:58 , Stefan Behnel wrote:
 
 These days, other Python implementations already provide the cElementTree
 module as a bare alias for ElementTree.py anyway, without emitting any
 warnings. Why should CPython be the only one that shouts at users for
 importing it?

Since all warnings are now silent by default (including DeprecationWarning),
it's less of a shout and more of an eyebrow-frown and a tut-tuting really.
___
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] Backwards incompatible sys.stdout.write() behavior in Python 3 (Was: [Python-ideas] Pythonic buffering in Py3 print())

[Xavier Morel]

On 2012-01-13, at 16:34 , anatoly techtonik wrote:
 Posting to python-dev as it is no more relates to the idea of improving
 print().
 
 
 sys.stdout.write() in Python 3 causes backwards incompatible behavior that
 breaks recipe for unbuffered character reading from stdin on Linux -
 http://code.activestate.com/recipes/134892/  At first I though that the
 problem is in the new print() function, but it appeared that the culprit is
 sys.stdout.write()
 
 Attached is a test script which is a stripped down version of the recipe
 above.
 
 If executed with Python 2, you can see the prompt to press a key (even
 though output on Linux is buffered in Python 2).
 With Python 3, there is not prompt until you press a key.
 
 Is it a bug or intended behavior? What is the cause of this break?
FWIW this is not restricted to Linux (the same behavior change can
be observed in OSX), and the script is overly complex you can expose
the change with 3 lines

import sys
sys.stdout.write('promt')
sys.stdin.read(1)

Python 2 displays prompt and terminates execution on [Return],
Python 3 does not display anything until [Return] is pressed.

Interestingly, the `-u` option is not sufficient to make
prompt appear in Python 3, the stream has to be flushed
explicitly unless the input is ~16k characters (I guess that's
an internal buffer size of some sort)
___
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] Backwards incompatible sys.stdout.write() behavior in Python 3 (Was: [Python-ideas] Pythonic buffering in Py3 print())

[Xavier Morel]

On 2012-01-13, at 17:19 , Antoine Pitrou wrote:
 
 -u forces line-buffering mode for stdout/stderr, which is already the
 default if they are wired to an interactive device (isattr() returning
 True).
Oh, I had not noticed the documentation had changed in Python 3 (in
Python 2 it stated that `-u` made IO unbuffered, on Python 3 it now
states that only binary IO is unbuffered and text IO remains
line-buffered). Sorry about that.

___
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 as a Metro-style App

[Xavier Morel]

On 2012-01-08, at 01:27 , Antoine Pitrou wrote:
 When you say MoveFile is absent, is MoveFileEx supported instead?
   WinRT strongly prefers asynchronous methods for all lengthy
 operations. The most likely call to use for moving files is
 StorageFile.MoveAsync.
 http://msdn.microsoft.com/en-us/library/windows/apps/br227219.aspx
 How does it translate to C?
From what I've read so far, it does not. WinRT inherits from COM (and the .net 
framework in some parts), so it seems like it's fundamentally an object-based 
API and the lowest-level language available is two variants of C++ (a template 
library and an extension to C++ which looks a bit like MS's older C++/CLI).

I have not seen any mention of C bindings for WinRT so far.
___
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] cpython (3.2): don't mention implementation detail

[Xavier Morel]

On 2011-12-20, at 11:08 , Antoine Pitrou wrote:
 But that's basically the only reason to invoke the
 `operator.attrgetter(foo)` ugliness, instead of writing the explicit
 and obvious `lambda x: x.foo`.
I don't agree with this, an attrgetter in the current namespace can be clearer 
than an explicit lambda in place, and more importantly when trying to fetch 
more than one attribute attrgetter is far superior to lambdas as far as I'm 
concerned.

I don't think I've ever seen `attrgetter` (or any of the other `operator` 
functions) advocated on basis of speed. This mention does not even exist in the 
Python 2 docs, which does not prevent people from using `operator`.
___
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

[Xavier Morel]

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

Re: [Python-Dev] Fixing the XML batteries

[Xavier Morel]

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] [PATCH] Adding braces to __future__

[Xavier Morel]

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

[Xavier Morel]

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

[Xavier Morel]

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__

[Xavier Morel]

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
 eventually successfully redeemed the mismatched parenthesis problem - at
 what cost?!).
 
 Not just difficult to 

Re: [Python-Dev] Deprecation policy

[Xavier Morel]

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

[Xavier Morel]

On 2011-11-28, at 13:06 , Nick Coghlan wrote:
 On Mon, Nov 28, 2011 at 7:53 PM, Xavier Morel catch-...@masklinn.net 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] Long term development external named branches and periodic merges from python

[Xavier Morel]

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] Promoting Python 3 [was: PyPy 1.7 - widening the sweet spot]

[Xavier Morel]

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]

[Xavier Morel]

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] order of Misc/ACKS

[Xavier Morel]

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] Hg tips

[Xavier Morel]

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

[Xavier Morel]

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] Heads up: Apple llvm gcc 4.2 miscompiles PEP 393

[Xavier Morel]

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

[Xavier Morel]

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] range objects in 3.x

[Xavier Morel]

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] PEP 393 Summer of Code Project

[Xavier Morel]

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] PEP 3154 - pickle protocol 4

[Xavier Morel]

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

[Xavier Morel]

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

[Xavier Morel]

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] Python 3.x and bytes

[Xavier Morel]

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

[Xavier Morel]

On 2011-05-19, at 09:49 , Nick Coghlan wrote:
 On Thu, May 19, 2011 at 5:10 AM, Eric Smith e...@trueblade.com 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

[Xavier Morel]

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 bde1.
 I hope you're joking. At best, the result should be bde\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] Linus on garbage collection

[Xavier Morel]

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] Status of json (simplejson) in cpython

[Xavier Morel]

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 solip...@pitrou.net 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