Re: [Python-Dev] cpython: PyUnicode_FromKindAndData() raises a ValueError if the kind is unknown

[Stephen J. Turnbull]

"Martin v. Löwis" writes:
 [Terry Reedy wrote:]

 > > Is it both technically possible (with hg) and socially permissible (with
 > > us) to edit another's commit message?
 > 
 > It's not technically possible,

Currently, in hg.  git has a mechanism for adding notes which are
automatically displayed along with the original commit message, and
bzr is considering introducing such a mechanism.  I'm not familiar
with the hg dev process (I use hg a lot, but so far it Just Works for
me :), but I would imagine they will move in that direction as well.

 > but it would be socially permissible to fix spelling mistakes.

The notes mechanism is not useful for fixing spelling mistakes unless
they make the message unintelligible, but I suppose it might expand
the range of socially permissible additions.
___
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 compatibility issue with Windows Developer Preview

[Brian Curtin]

On Mon, Oct 3, 2011 at 18:32, Ryan Wells (MP Tech Consulting LLC) <
v-ry...@microsoft.com> wrote:

>  Hello Python Developers,
>
> ** **
>
> I am a Program Manager with the Ecosystem Engineering team at Microsoft. We
> are tracking a issue with Python 3.2.2 on Windows Developer Preview when
> using Internet Explorer.
>

Is there any public bug tracker or other information for this on your end?
Sounds weird.

I’d like to connect directly with a developer on the project so that we can
> work closesly to resolve this issue.
>

There aren't many Windows devs around here, but while I'm one of them, I
don't currently have the bandwidth to devote to getting a Windows 8 setup
and working on this issue at the time. I think your best bet would be to
post as much information as you have and we can go from there, either from
myself or anyone available.

If you think you've nailed down a specific issue in Python,
http://bugs.python.org is our bug tracker.
___
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

[Python-Dev] Python compatibility issue with Windows Developer Preview

[Ryan Wells (MP Tech Consulting LLC)]

Hello Python Developers,

I am a Program Manager with the Ecosystem Engineering team at Microsoft. We are 
tracking a issue with Python 3.2.2 on Windows Developer Preview when using 
Internet Explorer.

At //BUILD/ in September, Microsoft announced the 
availability of the Windows Developer Preview, which includes IE10. We 
encourage you to download the Windows Developer 
Preview 
(http://msdn.microsoft.com/en-us/windows/apps/br229516) and to begin testing.

I'd like to connect directly with a developer on the project so that we can 
work closesly to resolve this issue.

Regards,

Ryan Wells
Microsoft PC Ecosystem Engineering Team
v-ry...@microsoft.com
___
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: PyUnicode_FromKindAndData() raises a ValueError if the kind is unknown

[Victor Stinner]

> > -assert(0);
> > +PyErr_SetString(PyExc_ValueError, "invalid kind");
> > 
> >  return NULL;
> >  
> >  }
> 
> Is that really a ValueError? It should only be a ValueError if the user
> could trigger that error. Otherwise it should be a SystemError.

You are right, ValueError is not best exception here. I used SystemError 
instead: see my commit 721bb2e59815.

PyUnicode_FromFormat() does still use ValueError in PyUnicode_FromFormatV:

PyErr_SetString(PyExc_ValueError,
"incomplete format key");

PyErr_SetString(PyExc_ValueError,
"width too big");

PyErr_SetString(PyExc_ValueError,
"prec too big");

PyErr_SetString(PyExc_ValueError,
"incomplete format");

PyErr_Format(PyExc_ValueError,
"unsupported format character '%c' (0x%x) "
"at index %zd",
(31<=c && c<=126) ? (char)c : '?',
(int)c,
fmtpos - 1);

PyErr_Format(PyExc_ValueError,
"PyUnicode_FromFormatV() expects an ASCII-encoded format "
"string, got a non-ASCII byte: 0x%02x",
(unsigned char)*f);

Should we also replace them by SystemError? It might break backward 
compatibility, but I do really hope that nobody relies on these errors ;-)

Victor
___
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: PyUnicode_FromKindAndData() raises a ValueError if the kind is unknown

[Martin v. Löwis]

> Is it both technically possible (with hg) and socially permissible (with
> us) to edit another's commit message?

It's not technically possible, but it would be socially permissible to
fix spelling mistakes.

With hg, editing commit messages would require some sort of patch queue
system, where the editor approves and manufactures commits out of the
data submitted by the actual author. As any patch queue system, it would
mean that commits aren't immediately available. Once they are available,
their data cannot be changed due to the distributed nature of the DVCS
(something that a centralized system would have no issues with).

Regards,
Martin
___
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: PyUnicode_FromKindAndData() raises a ValueError if the kind is unknown

[Terry Reedy]

On 10/3/2011 12:23 PM, "Martin v. Löwis" wrote:

Am 02.10.2011 17:46, schrieb Benjamin Peterson:



On 10/02/11 01:14, victor.stinner wrote:

   PyUnicode_FromKindAndData() raises a ValueError if the kind is unknown


Also, could I remind you that a better commit message is probably
"make PyUnicode_FromKindAndData raise a ValueError if the kind is
unknown".


I think this is asking too much. If we really want correct English
in all commit messages, we need to employ an editor who edits all
commit messages from non-native speakers.


Some months ago we discussed the fact that 'x does y' is ambiguous in 
commit messages because a) it could describe behavior 'now' either 
before or after the patch and b) it has been used by developers *both* 
ways. On the tracker, especially in titles, it routinely describes 
behavior 'now' before the patch. 'Make x do y' is not much of a change. 
Guido approved of such clarification.


Personnally, *I* know what Victor means as I believe he is consistent. 
But a new person might not. On the other hand, I do not want to 
discourage Victor from the great work he is doing.


Since both forms are correct English, I have not thought of this as a 
native versus non-native issue. But I could imagine that the translation 
into X might be less ambiguous to a native speaker of X.


Is it both technically possible (with hg) and socially permissible (with 
us) to edit another's commit message?


--
Terry Jan Reedy


___
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 3151 state

[Jeff Hardy]

On Mon, Oct 3, 2011 at 11:32 AM, Antoine Pitrou  wrote:

> On Mon, 3 Oct 2011 19:56:04 +0200
> Antoine Pitrou  wrote:
> >
> > Hello,
> >
> > I am back from holiday ;) and we haven't heard from other
> > implementations whether there was any difficulty for them in
> > implementing PEP 3151.
>
> Alex Gaynor and Jim Baker (thank you!) just told me on IRC that there
> shouldn't be any problem for their respective projects (PyPy and
> Jython, if I'm not totally confused).
>

I don't see any issues for IronPython either.

- Jeff
___
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 3151 state

[Antoine Pitrou]

On Mon, 3 Oct 2011 19:56:04 +0200
Antoine Pitrou  wrote:
> 
> Hello,
> 
> I am back from holiday ;) and we haven't heard from other
> implementations whether there was any difficulty for them in
> implementing PEP 3151.

Alex Gaynor and Jim Baker (thank you!) just told me on IRC that there
shouldn't be any problem for their respective projects (PyPy and
Jython, if I'm not totally confused).

Regards

Antoine.


___
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: PyUnicode_FromKindAndData() raises a ValueError if the kind is unknown

[Stephen J. Turnbull]

"Martin v. Löwis" writes:

 > > Also, could I remind you that a better commit message is probably
 > > "make PyUnicode_FromKindAndData raise a ValueError if the kind is
 > > unknown".
 > 
 > I think this is asking too much.

This distinction is important enough that it's worth asking non-native
speakers to *learn* this one idiom ("make Python do"), and all
developers to *use* it (or an equally unambiguous form, if they feel
like being original).

Whether that's a reasonable burden for individual non-natives is going
to depend on the individual, of course.  But asking is not out of line.

 > I believe Victor formulated this in the spirit of

Sure, one can figure that out -- but that's a lot of effort to ask of
readers of logs.  In general it requires familiarity with the patch
being documented.

___
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] RFC: Add a new builtin strarray type to Python?

[Victor Stinner]

Le lundi 3 octobre 2011 18:04:57, vous avez écrit :
> Why are you checking, in unicode_resizable, whether the string is from
> unicode_latin1? If it is, then it should have a refcount of at least 2,
> so the very first test in the function should already exclude it.

There is also a test on unicode_empty. Singletons should not be modified, but 
you are right, ref count is always at least 2 (when calling 
unicode_resizable).

Changeset 6fbc5e9141fc replaces tests by assertions.

Victor
___
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

[Python-Dev] PEP 3151 state

[Antoine Pitrou]

Hello,

I am back from holiday ;) and we haven't heard from other
implementations whether there was any difficulty for them in
implementing PEP 3151. Did I miss something (it's difficult to keep up
with many messages on a small netbook with a screen broken by a
batman-like pattern obscuring the right 20% :-)) ?

Regards

Antoine.


___
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: PyUnicode_FromKindAndData() raises a ValueError if the kind is unknown

[Martin v. Löwis]

Am 02.10.2011 17:46, schrieb Benjamin Peterson:
> 2011/10/2 Georg Brandl :
>> On 10/02/11 01:14, victor.stinner wrote:
>>> http://hg.python.org/cpython/rev/9124a00df142
>>> changeset:   72573:9124a00df142
>>> parent:  72571:fa0b1e50270f
>>> user:Victor Stinner 
>>> date:Sat Oct 01 23:48:37 2011 +0200
>>> summary:
>>>   PyUnicode_FromKindAndData() raises a ValueError if the kind is unknown
> 
> Also, could I remind you that a better commit message is probably
> "make PyUnicode_FromKindAndData raise a ValueError if the kind is
> unknown".

I think this is asking too much. If we really want correct English
in all commit messages, we need to employ an editor who edits all
commit messages from non-native speakers.

I believe Victor formulated this in the spirit of

PyUnicode_FromKindAndData() "now" raises a ValueError if the kind is unknown

which, to me, is equivalent to the (to me) correct formulations

PyUnicode_FromKindAndData() will now raise a ValueError if the kind is
unknown

and

PyUnicode_FromKindAndData() is now raising a ValueError if the kind is
unknown

Of course, I'll encourage Victor to keep on mastering the English
language as much as anybody else.

Regards,
Martin
___
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: request for keeping PyUnicode_EncodeDecimal()

[Martin v. Löwis]

> What I'm looking for is a public function that is silently updated if
> python-dev decides to accept other numerical input. As I understand
> from your comments below, PyUnicode_EncodeDecimal() is frozen, so
> that function does indeed not help.
> 
> I would consider it reasonable for PyUnicode_TransformDecimalAndSpaceToASCII()
> to be documented as:
> 
>   "This function might accept different numerical input in the future."
> 
> 
> The reason is that some people would like to accept additional input
> (see #6632), while others would like to restrict input. If there is
> a function that will always track whatever will be decided, extension
> authors don't have to worry about being up-to-date.

I don't think it's possible to promise such a thing. Predictions
are difficult and all that. If somebody knew what the function should
do in the future, then it would be best to change it now to do that.

Rather expect that whenever functions get deprecated but not removed
that they keep the semantics they had, for use in code that relies
not only on the function name, but also on the function semantics (or
else there may not be a point in keeping the function at all if it
suddenly changes its behavior).

>>> Will PyUnicode_TransformDecimalAndSpaceToASCII() be public?
>>
>> It's already included in 3.2, so it can't be removed that easily.
>> I wish it had been private, though - we have way too many API functions
>> dealing with Unicode.
> 
> I can find PyUnicode_TransformDecimalToASCII() in 3.2, but not
> PyUnicode_TransformDecimalAndSpaceToASCII().

Ah, so there is still a chance to make it private then. I plan to
go over all new APIs for 3.3, and will propose to make all those
private where nobody can argue for general utility. The longer the
function name, the less is the utility.

PyMartin_SendThisMessageAboutDecimalParsingToStefan-ly y'rs
Martin
___
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] RFC: Add a new builtin strarray type to Python?

[Martin v. Löwis]

> I restored this hack in Python 3.3 using PyUnicode_Append() in ceval.c and by 
> optimizing PyUnicode_Append() (try to append in-place). str+=str is closer 
> again to ''.join:

Why are you checking, in unicode_resizable, whether the string is from
unicode_latin1? If it is, then it should have a refcount of at least 2,
so the very first test in the function should already exclude it.

Regards,
Martin
___
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] RFC: Add a new builtin strarray type to Python?

[Victor Stinner]

Le 03/10/2011 04:19, Victor Stinner a écrit :

I restored this hack in Python 3.3 using PyUnicode_Append() in ceval.c and by
optimizing PyUnicode_Append() (try to append in-place). str+=str is closer
again to ''.join:

str += str: 696 ms
''.join():  547 ms

I disabled temporary the optimization for wstr string in PyUnicode_Resize()
because of a bug. I disabled completly resize on Windows because of another
bug.


Ok, bugs fixed, all "resize" optimizations are now enabled:

Python 3.3
str += str: 119 ms
''.join() : 130 ms
StringIO.join : 147 ms
StringBuilder : 404 ms
array('u'): 979 ms

Hum, str+=str is now the fastest method, even faster than ''.join() !? 
It's maybe time to optimize str.join ;-)


Victor
___
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] counterintuitive behavior (bug?) in Counter with +=

[INADA Naoki]

+1

Because Counter is mutable object, I think += should mutate left side object.

On Mon, Oct 3, 2011 at 7:12 PM, Lars Buitinck  wrote:
> Hello,
>
> [First off, I'm not a member of this list, so please Cc: me in a reply!]
>
> I've found some counterintuitive behavior in collections.Counter while
> hacking on the scikit-learn project [1]. I wanted to use a bunch of
> Counters to do some simple term counting in a set of documents,
> roughly as follows:
>
>    count_total = Counter()
>    for doc in documents:
>        count_current = Counter(analyze(doc))
>        count_total += count_current
>        count_per_doc.append(count_current)
>
> Because we target Python 2.5+, I implemented a lightweight replacement
> with just the functionality we need, including __iadd__, but then my
> co-developer ran the above code on Python 2.7 and performance was
> horrible. After some digging, I found out that Counter [2] does not
> have __iadd__ and += copies the entire left-hand side in __add__!
>
> I also figured out that I should use the update method instead, which
> I will, but I still find that uglier than +=. I would submit a patch
> to implement __iadd__, but I first want to know if that's considered
> the right behavior, since it changes the semantics of +=:
>
>    >>> from collections import Counter
>    >>> a = Counter([1,2,3])
>    >>> b = a
>    >>> a += Counter([3,4,5])
>    >>> a is b
>    False
>
> would become
>
>    # snip
>    >>> a is b
>    True
>
> TIA,
> Lars
>
>
> [1] 
> https://github.com/scikit-learn/scikit-learn/commit/de6e93094499e4d81b8e3b15fc66b6b9252945af
> [2] http://hg.python.org/cpython/file/tip/Lib/collections/__init__.py#l399
>
>
> --
> Lars Buitinck
> Scientific programmer, ILPS
> University of Amsterdam
> ___
> 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/songofacandy%40gmail.com
>



-- 
INADA Naoki  
___
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

[Python-Dev] counterintuitive behavior (bug?) in Counter with +=

[Lars Buitinck]

Hello,

[First off, I'm not a member of this list, so please Cc: me in a reply!]

I've found some counterintuitive behavior in collections.Counter while
hacking on the scikit-learn project [1]. I wanted to use a bunch of
Counters to do some simple term counting in a set of documents,
roughly as follows:

count_total = Counter()
for doc in documents:
count_current = Counter(analyze(doc))
count_total += count_current
count_per_doc.append(count_current)

Because we target Python 2.5+, I implemented a lightweight replacement
with just the functionality we need, including __iadd__, but then my
co-developer ran the above code on Python 2.7 and performance was
horrible. After some digging, I found out that Counter [2] does not
have __iadd__ and += copies the entire left-hand side in __add__!

I also figured out that I should use the update method instead, which
I will, but I still find that uglier than +=. I would submit a patch
to implement __iadd__, but I first want to know if that's considered
the right behavior, since it changes the semantics of +=:

>>> from collections import Counter
>>> a = Counter([1,2,3])
>>> b = a
>>> a += Counter([3,4,5])
>>> a is b
False

would become

# snip
>>> a is b
True

TIA,
Lars


[1] 
https://github.com/scikit-learn/scikit-learn/commit/de6e93094499e4d81b8e3b15fc66b6b9252945af
[2] http://hg.python.org/cpython/file/tip/Lib/collections/__init__.py#l399


-- 
Lars Buitinck
Scientific programmer, ILPS
University of Amsterdam
___
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 Core Tools

[renaud]

Maciej Fijalkowski  gmail.com> writes:

> https://bitbucket.org/pypy/pypy/src/59460302c713/lib_pypy/disassembler.py
> 
> this might be of interest. It's like dis module except it creates
> objects instead of printing them
> 

I think that Issue11816 (under review) aims at extending the dis module in a
similar direction:
Refactor the dis module to provide better building blocks for bytecode analysis
http://bugs.python.org/issue11816

renaud


___
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] RFC: Add a new builtin strarray type to Python?

[Hrvoje Niksic]

On 10/02/2011 06:34 PM, Alex Gaynor wrote:

There are a number of issues that are being conflated by this thread.

1) Should str += str be fast. In my opinion, the answer is an obvious and
resounding no. Strings are immutable, thus repeated string addition is
O(n**2). This is a natural and obvious conclusion. Attempts to change this
are only truly possible on CPython, and thus create a worse enviroment for
other Pythons, as well as a quite misleading, as they'll be extremely
brittle. It's worth noting that, to my knowledge, JVMs haven't attempted
hacks like this.


CPython is already misleading and ahead of JVM, because the str += str 
optimization has been applied to Python 2 some years ago - see

http://hg.python.org/cpython-fullhistory/rev/fb6ffd290cfb?revcount=480

I like Python's immutable strings and consider it a good default for 
strings.  Nevertheless a mutable string would be useful for those 
situations when you know you are about to manipulate a string-like 
object a number of times, where immutable strings require too many 
allocations.


I don't think Python needs a StringBuilder - constructing strings using 
a list of strings or StringIO is well-known and easy.  Mutable strings 
are useful for the cases where StringBuilder doesn't suffice because you 
need modifications other than appends.  This is analogous to file writes 
- in practice most of them are appends, but sometimes you also need to 
be able to seek and write stuff in the middle.


Hrvoje
___
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