Andrew Barnert via Python-Dev writes:
> That doesn't mean the problem can't be solved. Apple solved their
> equivalent problem, albeit by sacrificing backward compatibility in
> a way Microsoft can't get away with. I haven't seen a MacRoman or
> Shift-JIS filename since they broke the last
Victor Stinner writes:
> It's annoying that 8 years after the release of Python 3.0, Python 3
> is still stuck by Python 2 :-(
I prefer to think of it as the irritant that reminds me that I am very
much alive, and so is Python, vibrantly so.
___
On Wed, Feb 10, 2016 at 1:11 AM, Phil Thompson
wrote:
> I understand now. The documentation, as it stands, is correct and consistent
> but (to me) the meaning of Optional is completely counter-intuitive. What you
> suggest with str = ... is exactly what I need.
On 10 Feb 2016, at 5:52 pm, Guido van Rossum wrote:
>
> On Wed, Feb 10, 2016 at 1:11 AM, Phil Thompson
> wrote:
>> I understand now. The documentation, as it stands, is correct and consistent
>> but (to me) the meaning of Optional is completely
On Wed, Feb 10, 2016 at 10:01 AM, Phil Thompson
wrote:
> On 10 Feb 2016, at 5:52 pm, Guido van Rossum wrote:
[...]
> That should do it, thanks. A followup question...
>
> Is...
>
> def foo(bar: str = Optional[str])
>
> ...valid? In other words,
On Wednesday, February 10, 2016 6:50 AM, Stephen J. Turnbull
wrote:
> Andrew Barnert via Python-Dev writes:
>
>> That doesn't mean the problem can't be solved. Apple solved their
>> equivalent problem, albeit by sacrificing backward compatibility in
>> a way Microsoft
On Wed, 10 Feb 2016 at 14:21 Georg Brandl wrote:
> This came up in python-ideas, and has met mostly positive comments,
> although the exact syntax rules are up for discussion.
>
> cheers,
> Georg
>
>
>
Hi,
I hope the question is not too silly, but why I would like to understand
the advantages of having both re.match() and re.search(). Wouldn't be
more clear to have just one function with one additional parameters like
this:
re.search(regexp, text, from_beginning=True|False) ?
In this way
This came up in python-ideas, and has met mostly positive comments,
although the exact syntax rules are up for discussion.
cheers,
Georg
PEP: 515
Title: Underscores in Numeric Literals
Version: $Revision$
On 2/10/2016 2:20 PM, Georg Brandl wrote:
This came up in python-ideas, and has met mostly positive comments,
although the exact syntax rules are up for discussion.
cheers,
Georg
PEP: 515
Title: Underscores in
On 10 February 2016 at 22:20, Georg Brandl wrote:
> This came up in python-ideas, and has met mostly positive comments,
> although the exact syntax rules are up for discussion.
+1 on the PEP. Is there any value in allowing underscores in strings
passed to the Decimal
Hi,
Le 10/02/2016 22:59, Luca Sangiacomo a écrit :
Hi,
I hope the question is not too silly, but why I would like to
understand the advantages of having both re.match() and re.search().
Wouldn't be more clear to have just one function with one additional
parameters like this:
On Wed, Feb 10, 2016 at 03:45:48PM -0800, Andrew Barnert via Python-Dev wrote:
> On Feb 10, 2016, at 14:20, Georg Brandl wrote:
>
> First, general questions: should the PEP mention the Decimal constructor?
> What about int and float (I'd assume int(s) continues to work as
On 02/11/2016 02:16 AM, Martin Panter wrote:
> I have occasionally wondered about this missing feature.
>
> On 10 February 2016 at 22:20, Georg Brandl wrote:
>> Abstract and Rationale
>> ==
>>
>> This PEP proposes to extend Python's syntax so that
On Feb 10, 2016, at 16:21, Steven D'Aprano wrote:
>
>> On Wed, Feb 10, 2016 at 03:45:48PM -0800, Andrew Barnert via Python-Dev
>> wrote:
>> On Feb 10, 2016, at 14:20, Georg Brandl wrote:
>>
>> First, general questions: should the PEP mention the Decimal
On 02/11/2016 12:45 AM, Andrew Barnert via Python-Dev wrote:
> On Feb 10, 2016, at 14:20, Georg Brandl wrote:
>
> First, general questions: should the PEP mention the Decimal constructor?
> What about int and float (I'd assume int(s) continues to work as always,
> while int(s,
On 02/10/2016 11:35 PM, Brett Cannon wrote:
>> Examples::
>>
>> # grouping decimal numbers by thousands
>> amount = 10_000_000.0
>>
>> # grouping hexadecimal addresses by words
>> addr = 0xDEAD_BEEF
>>
>> # grouping bits into bytes in a binary
On Wednesday, February 10, 2016 12:47 AM, Victor Stinner
wrote:
> > 2016-02-10 9:30 GMT+01:00 Paul Moore :
>> Whether removing the bytes interface is feasible, given that there's
>> then no way that works across Python 2 and 3 of writing code
Executive summary:
Code pages and POSIX locales aren't solutions, they're the Original Sin.
Steve Dower writes:
> On 09Feb2016 2017, Stephen J. Turnbull wrote:
> > > The problem here is the protocol that Python uses to return
> > > bytes paths, and that protocol is inconsistent between
On Feb 9, 2016, at 20:17, Stephen J. Turnbull wrote:
>> It really requires going through all the OS calls and either (a) making
>> them consistently decode bytes to str using the declared FS encoding
>> (currently 'mbcs', but I see no reason we can't make it 'utf_8'),
>
>
2016-02-10 11:18 GMT+01:00 Steven D'Aprano :
> [steve@ando ~]$ python3.3 -c 'print(open(b"/tmp/abc\xD8\x01", "r").read())'
> Hello World
>
> [steve@ando ~]$ python3.3 -c 'print(open("/tmp/abc\xD8\x01", "r").read())'
> Traceback (most recent call last):
> File "", line 1, in
On Wed, Feb 10, 2016 at 12:41:08PM +1100, Chris Angelico wrote:
> On Wed, Feb 10, 2016 at 12:37 PM, Steve Dower wrote:
> > I really don't like the idea of not being able to use bytes in cross
> > platform code. Unless it's become feasible to use Unicode for lossless
> >
On 10 February 2016 at 08:00, Stephen J. Turnbull wrote:
>> The earlier issue was that that doesn't work (e.g. a bytes path
> > from os.scandir couldn't be passed back into open()).
>
> My purely-from-the-user-side take is that that's just a bug in
> os.scandir that should be
2016-02-10 9:30 GMT+01:00 Paul Moore :
> Whether removing the bytes interface is feasible, given that there's
> then no way that works across Python 2 and 3 of writing code that
> manipulates the sort of bytes-that-use-multiple-encodings data that
> you mention, is a separate
> On 9 Feb 2016, at 11:48 pm, Guido van Rossum wrote:
>
> [Phil]
I found the documentation confusing regarding Optional. Intuitively it
seems to be the way to specify arguments with default values. However it
is explained in terms of (for example) Union[str,
On 10 February 2016 at 08:45, Victor Stinner wrote:
> 2016-02-10 9:30 GMT+01:00 Paul Moore :
>> Whether removing the bytes interface is feasible, given that there's
>> then no way that works across Python 2 and 3 of writing code that
>> manipulates
On 08.02.16 16:32, Victor Stinner wrote:
On Python 2, it wasn't possible to use Unicode for filenames, many
functions fail badly with Unicode, especially when you mix bytes and
Unicode.
Even not all os functions support Unicode.
See http://bugs.python.org/issue18695.
On 10 February 2016 at 06:54, Guido van Rossum wrote:
> [Just adding to Andrew's response]
>
> On Tue, Feb 9, 2016 at 9:58 AM, Andrew Barnert via Python-Dev
> wrote:
>> On Feb 9, 2016, at 03:44, Phil Thompson wrote:
>>>
>>>
On Wed, Feb 10, 2016 at 10:59:18PM +0100, Luca Sangiacomo wrote:
> Hi,
> I hope the question is not too silly, but why I would like to understand
> the advantages of having both re.match() and re.search(). Wouldn't be
> more clear to have just one function with one additional parameters like
>
On Feb 10, 2016, at 14:20, Georg Brandl wrote:
First, general questions: should the PEP mention the Decimal constructor? What
about int and float (I'd assume int(s) continues to work as always, while
int(s, 0) gets the new behavior, but if that isn't obviously true, it may be
On Feb 10, 2016, at 15:11, eryk sun wrote:
>
> On Wed, Feb 10, 2016 at 2:30 PM, Andrew Barnert via Python-Dev
> wrote:
>> [^3]: Say you write a program that assumes it will only be run on Shift-JIS
>> systems, and you use
>> CreateFileA to create a
The Mersenne Twister is no longer regarded as quite state-of-the art
because it can get into states that produce long sequences that are
not very random.
There is a variation on MT called WELL that has better properties
in this regard. Does anyone think it would be a good idea to replace
MT with
It looks like the implementation https://bugs.python.org/issue26331
only changes the Python parser.
What about other functions converting strings to numbers at runtime
like int(str) and float(str)? Paul also asked for Decimal(str).
Victor
___
On 2016-02-10 22:35, Brett Cannon wrote:
[snip]
Examples::
# grouping decimal numbers by thousands
amount = 10_000_000.0
# grouping hexadecimal addresses by words
addr = 0xDEAD_BEEF
# grouping bits into bytes in a binary literal
On Wed, Feb 10, 2016 at 2:30 PM, Andrew Barnert via Python-Dev
wrote:
> [^3]: Say you write a program that assumes it will only be run on Shift-JIS
> systems, and you use
> CreateFileA to create a file named "ハローワールド". The actual bytes you're sending
> are cp436
> for
On Wed, Feb 10, 2016 at 11:20:38PM +0100, Georg Brandl wrote:
> This came up in python-ideas, and has met mostly positive comments,
> although the exact syntax rules are up for discussion.
Nicely done. But I would change the restrictions to a simpler version.
Instead of five rules to learn:
>
On 02/10/2016 04:04 PM, Steven D'Aprano wrote:
> change to a single rule "one or more underscores may appear between
> two (hex)digits, but otherwise nowhere else". That's much simpler to
> understand than a series of restrictions as given above.
I like the simpler rule, but I would also allow
On Wed, Feb 10, 2016 at 10:53:09PM +, Paul Moore wrote:
> On 10 February 2016 at 22:20, Georg Brandl wrote:
> > This came up in python-ideas, and has met mostly positive comments,
> > although the exact syntax rules are up for discussion.
>
> +1 on the PEP. Is there any
I have occasionally wondered about this missing feature.
On 10 February 2016 at 22:20, Georg Brandl wrote:
> Abstract and Rationale
> ==
>
> This PEP proposes to extend Python's syntax so that underscores can be used in
> integral and floating-point number
39 matches
Mail list logo