[Python-Dev] Excess help() output

[anatoly techtonik]

Hi,

The help() output is confusing for beginners:

  >>> class B(object):
  ...   pass
  ...
  >>> help(B)
  Help on class B in module __main__:

  class B(__builtin__.object)
   |  Data descriptors defined here:
   |
   |  __dict__
   |  dictionary for instance variables (if defined)
   |
   |  __weakref__
   |  list of weak references to the object (if defined)

Is it possible to remove this section from help output?
Why is it here at all?

  >>> dir(B)
  ['__class__', '__delattr__', '__dict__', '__doc__', '__format__',
'__getattribute__', '__hash__', '__init__', '__module__', '__new__',
'__reduce__', '__reduce_ex__', '__repr__', '__setattr__',
'__sizeof__', '__str__', '__subclasshook__', '__weakref__']

-- 
anatoly t.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] subprocess research - max limit for piped output

[anatoly techtonik]

I am trying to figure out what is maximum size
for piped input in subprocess.check_output()

I've got limitation of about 500Mb after which
Python exits with MemoryError without any
additional details.

I have only 2.76Gb memory used out of 8Gb,
so what limit do I hit?

1. subprocess output read buffer
2. Python limit on size of variable
3. some OS limit on output pipes

Testcase attached.


C:\discovery\interface\subprocess>py dead.py
Testing size: 520Mb
..truncating to 545259520
..
Traceback (most recent call last):
  File "dead.py", line 66, in 
backticks(r'type largefile')
  File "dead.py", line 36, in backticks
output = subprocess.check_output(command, shell=True)
  File "C:\Python27\lib\subprocess.py", line 567, in check_output
output, unused_err = process.communicate()
  File "C:\Python27\lib\subprocess.py", line 791, in communicate
stdout = _eintr_retry_call(self.stdout.read)
  File "C:\Python27\lib\subprocess.py", line 476, in _eintr_retry_call
return func(*args)
MemoryError
The process tried to write to a nonexistent pipe.

-- 
anatoly t.
import subprocess

# --- replacing shell backticks ---
# 
https://docs.python.org/2/library/subprocess.html#replacing-bin-sh-shell-backquote
#   output=`mycmd myarg`
#   output = check_output(["mycmd", "myarg"])
# not true, because mycmd is not passed to shell
try:
pass #output = subprocess.check_output(["mycmd", "myarg"], shell=True)
except OSError as ex:
# command not found.
# it is impossible to catch output here, but shell outputs
# message to stderr, which backticks doesn't catch either
output = ''
except subprocess.CalledProcessError as ex:
output = ex.output
# ^ information about error condition is lost
# ^ output in case of OSError is lost

# ux notes:
# - `mycmd myarg` > ["mycmd", "myarg"]
# - `` is invisible
#   subprocess.check_output is hardly rememberable
# - exception checking is excessive and not needed
#   (common pattern is to check return code)


def backticks(command):
   '''
   - no return code
   - no stderr capture
   '''
   try:
   # this doesn't escape shell patterns, such as:
   # ^ (windows cmd.exe shell)
   output = subprocess.check_output(command, shell=True)
   except OSError as ex:
   # command not found.
   # it is impossible to catch output here, but shell outputs
   # message to stderr, which backticks doesn't catch either
   output = ''
   except subprocess.CalledProcessError as ex:
   output = ex.output
   return output


import os
for size in range(520, 600, 2):
print("Testing size: %sMb" % size)
#cursize = os.path.getsize("largefile")
with open("largefile", "ab") as data:
data.seek(0, 2)
cursize = data.tell()
#print(cursize)
limit = size*1024**2
if cursize > limit:
print('..truncating to %s' % limit)
data.truncate(limit)
else:
print('..extending to %s' % limit)
while cursize < limit:
toadd = min(100, limit-cursize)
data.write('1'*99+'\n')
cursize += 100
print("..")
backticks(r'type largefile')

___
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] bytes-like objects

[anatoly techtonik]

That's a cool stuff. `bytes-like object` is really a much better name for users.
___
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 2.x and 3.x use survey, 2014 edition

[anatoly techtonik]

On Wed, Dec 17, 2014 at 12:56 AM, Guido van Rossum  wrote:
> This thread hasn't been productive for a really long time now.

I agree. The constructive way would be to concentrate on looking for
causes. I don't know if there is a discipline of "programming language
usability" in computer science, but now is a good moment to apply 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

[Python-Dev] python 2.7.9 regression in argparse?

[anatoly techtonik]

https://github.com/nickstenning/honcho/pull/121

-- 
anatoly t.
___
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] hg vs Github [was: PEP 481 - Migrate Some Supporting Repositories to Git and Github]

[anatoly techtonik]

On Mon, Dec 1, 2014 at 8:37 PM, Jim J. Jewett  wrote:
>
>> What I really don't understand is why this discussion is hg v.
>> GitHub, when it should be hg v. git. Particular hosting is
>> a secondary issue
>
> I think even the proponents concede that git isn't better enough
> to justify a switch in repositories.
>
> They do claim that GitHub (the whole environment; not just the
> hosting) is so much better that a switch to GitHub is justified.
>
> Github + hg offers far fewer benefits than Github + git, so also
> switching to git is part of the price.  Whether that is an
> intolerable markup or a discount is disputed, as are the value
> of several other costs and benefits.

git - GitHub < hg + hgweb
GitHub + hg < hg + hgweb
GitHub + git > hg + hgweb
GitHub + git <= hg + hgweb + Roundup
GitHub + git < hg + hgweb + Roundup + Rietveld

(GitHub + git) * Python = 0
(hg + hgweb) * Python = 1


There is also a question of support. Obviously Roundup will degrade
over time if there is economic support for coordination action for
people working on it, no matter how strong is their open source and
community spirits. It was fun back in the days, but now time control
and "human resource mining" techniques are so perfect that I hardly
imagine someone to have free time to work on community open
source projects.

With no time to support our own dogfood, the community will have
to switch to GitHub sooner or later, because that is the thing that
saves time so valuable. GitLab could be a open source alternative
if Python community chooses to be more tolerant to use Ruby tools
dogfood in its ecosystem.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] 2.7.9 regression in argparse

[anatoly techtonik]

Just a pointer for possible regression http://bugs.python.org/issue23058

-- 
anatoly t.
___
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] Automated testing of patches from bugs.python.org

[anatoly techtonik]

On Tue, May 19, 2015 at 11:37 PM, Terry Reedy  wrote:
> On 5/19/2015 11:02 AM, Kushal Das wrote:
>>
>> Hi,
>>
>> With the help of CentOS project I am happy to announce an automated
>> system [1] to test patches from bugs.python.org. This can be fully
>> automated
>> to test the patches whenever someone uploads a patch in the roundup, but
>> for now it accepts IRC commands on #python-dev channel. I worked on a
>> docker based prototype during sprints in PyCon.
>>
>> How to use it?
>> ---
>>
>> 1. Join #python-dev on irc.freenode.net.
>> 2. Ask for test privilege  from any one of kushal,Taggnostr,bitdancer
>> 3. They will issue a simple command. #add: YOUR_NICK_NAME
>> 4. You can then test by issuing the following command in the channel:
>>
>>  #test: BUGNUMBER
>>  like #test: 21271
>
>
> What if there are multiple patches on the issue?  Pick the latest?
> This is not correct if someone follows up a patch with a 2.7 backport, or if
> there are competing patches.

Here is the code that checks how much outstanding patches a certain
module has by downloading all patches from open issues, parsing them
and comparing the paths. It is possible to reuse the parser to check paths
in patch against paths present in certain Python versions, or add different
heuristics.

https://bitbucket.org/techtonik/python-stdlib

All this is pure Python and should work cross-platform too.


This was intended to add status for bugs.python.org, but the work on
Roundup had stalled due to uncertainty and despair on how to handle
utf-8 (internal to Roundup) vs unicode (internal to Jinja2) in this issue:
http://issues.roundup-tracker.org/issue2550811
The root of the problem is that Python 2.7 uses 'ascii' and not 'utf-8'
internally, so Jinja2 engine fails with 'ascii' ordinal not in range
somewhere in the way. Need an expert advice how to handle that, because
my brain power is not enough to process 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] Mingw help

[anatoly techtonik]

On Fri, Jun 5, 2015 at 2:24 AM, Steve Dower  wrote:
> If you have an interest in linking to the Windows builds of Python 2.7 and
> 3.5+ using mingw, please visit http://bugs.python.org/issue24385
>
> Unless someone can provide me with the One True Way to generate a lib that
> will work for everyone, I'm going to replace the lib file with instructions
> on how to generate it with your own tools. I've done enough guessing and
> need someone who actually uses mingw to step up and help out.

I use MinGW with SCons to build RHVoice and Wesnoth. I haven't seen a problem
to use resulting .dll from ctypes, so as far as I know, if you're not
using SEH, the
resulting libraries should be compatible between MS tools and MinGW.

Is that what are you asking?
-- 
anatoly t.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Assign(expr* targets, expr value) - why targetS?

[anatoly techtonik]

http://hg.python.org/cpython/file/1ee45eb6aab9/Parser/Python.asdl

In Assign(expr* targets, expr value), why the first argument is a list?
--
anatoly t.
___
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] Assign(expr* targets, expr value) - why targetS?

[anatoly techtonik]

On Sun, Nov 10, 2013 at 8:34 AM, Benjamin Peterson  wrote:
> 2013/11/10 anatoly techtonik :
>> http://hg.python.org/cpython/file/1ee45eb6aab9/Parser/Python.asdl
>>
>> In Assign(expr* targets, expr value), why the first argument is a list?
>
> x = y = 42

Thanks.

Speaking of this ASDL. `expr* targets` means that multiple entities of
`expr` under the name 'targets' can be passed to Assign statement.
Assign uses them as left value. But `expr` definition contains things
that can not be used as left side assignment targets:

expr = BoolOp(boolop op, expr* values)
 | BinOp(expr left, operator op, expr right)
 ...
 | Str(string s) -- need to specify raw, unicode, etc?
 | Bytes(bytes s)
 | NameConstant(singleton value)
 | Ellipsis

 -- the following expression can appear in assignment context
 | Attribute(expr value, identifier attr, expr_context ctx)
 | Subscript(expr value, slice slice, expr_context ctx)
 | Starred(expr value, expr_context ctx)
 | Name(identifier id, expr_context ctx)
 | List(expr* elts, expr_context ctx)
 | Tuple(expr* elts, expr_context ctx)

If I understand correctly, this is compiled into C struct definitions
(Python-ast.c), and there is a code to traverse the structure, but
where is code that validates that the structure is correct? Is it done
on the first level - text file parsing, before ASDL is built? If so,
then what is the role of this ADSL exactly that the first step is
unable to solve?

Is it possible to fix ADSL to move `expr` that are allowed in Assign
into `expr` subset? What effect will it achieve? I mean - will ADSL
compiler complain about wrong stuff on the left side, or it will still
be a role of some other component. Which one?
___
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] Assign(expr* targets, expr value) - why targetS?

[anatoly techtonik]

On Tue, Nov 12, 2013 at 5:08 PM, Benjamin Peterson  wrote:
> 2013/11/12 anatoly techtonik :
>> On Sun, Nov 10, 2013 at 8:34 AM, Benjamin Peterson  
>> wrote:
>>> 2013/11/10 anatoly techtonik :
>>>> http://hg.python.org/cpython/file/1ee45eb6aab9/Parser/Python.asdl
>>>>
>>>> In Assign(expr* targets, expr value), why the first argument is a list?
>>>
>>> x = y = 42
>>
>> Thanks.
>>
>> Speaking of this ASDL. `expr* targets` means that multiple entities of
>> `expr` under the name 'targets' can be passed to Assign statement.
>> Assign uses them as left value. But `expr` definition contains things
>> that can not be used as left side assignment targets:
>>
>> expr = BoolOp(boolop op, expr* values)
>>  | BinOp(expr left, operator op, expr right)
>>  ...
>>  | Str(string s) -- need to specify raw, unicode, etc?
>>  | Bytes(bytes s)
>>  | NameConstant(singleton value)
>>  | Ellipsis
>>
>>  -- the following expression can appear in assignment context
>>  | Attribute(expr value, identifier attr, expr_context ctx)
>>  | Subscript(expr value, slice slice, expr_context ctx)
>>  | Starred(expr value, expr_context ctx)
>>  | Name(identifier id, expr_context ctx)
>>  | List(expr* elts, expr_context ctx)
>>  | Tuple(expr* elts, expr_context ctx)
>>
>> If I understand correctly, this is compiled into C struct definitions
>> (Python-ast.c), and there is a code to traverse the structure, but
>> where is code that validates that the structure is correct? Is it done
>> on the first level - text file parsing, before ASDL is built? If so,
>> then what is the role of this ADSL exactly that the first step is
>> unable to solve?
>
> Only valid expression targets are allowed during AST construction. See
> set_expr_context in ast.c.

Oh my. Now there is also CST in addition to AST. This stuff -
http://docs.python.org/devguide/ - badly needs diagrams about data
transformation toolchain from Python source code to machine
execution instructions. I'd like some pretty stuff, but raw blogdiag
hack will do the job http://blockdiag.com/en/blockdiag/index.html

There is no set_expr_context in my copy of CPython code, which
seems to be some alpha of Python 3.4

>> Is it possible to fix ADSL to move `expr` that are allowed in Assign
>> into `expr` subset? What effect will it achieve? I mean - will ADSL
>> compiler complain about wrong stuff on the left side, or it will still
>> be a role of some other component. Which one?
>
> I'm not sure what you mean by an `expr` subset.

Transform this:

expr = BoolOp(boolop op, expr* values)
 | BinOp(expr left, operator op, expr right)
 ...
 | Str(string s) -- need to specify raw, unicode, etc?
 | Bytes(bytes s)
 | NameConstant(singleton value)
 | Ellipsis

 -- the following expression can appear in assignment context
 | Attribute(expr value, identifier attr, expr_context ctx)
 | Subscript(expr value, slice slice, expr_context ctx)
 | Starred(expr value, expr_context ctx)
 | Name(identifier id, expr_context ctx)
 | List(expr* elts, expr_context ctx)
 | Tuple(expr* elts, expr_context ctx)

to this:

expr = BoolOp(boolop op, expr* values)
 | BinOp(expr left, operator op, expr right)
 ...
 | Str(string s) -- need to specify raw, unicode, etc?
 | Bytes(bytes s)
 | NameConstant(singleton value)
 | Ellipsis

 -- the following expression can appear in assignment context
 | expr_asgn

 expr_asgn =
   Attribute(expr value, identifier attr, expr_context ctx)
 | Subscript(expr value, slice slice, expr_context ctx)
 | Starred(expr value, expr_context ctx)
 | Name(identifier id, expr_context ctx)
 | List(expr* elts, expr_context ctx)
 | Tuple(expr* elts, expr_context ctx)
___
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] Assign(expr* targets, expr value) - why targetS?

[anatoly techtonik]

On Fri, Nov 15, 2013 at 12:54 PM, anatoly techtonik  wrote:
> On Tue, Nov 12, 2013 at 5:08 PM, Benjamin Peterson  
> wrote:
>> 2013/11/12 anatoly techtonik :
>>> On Sun, Nov 10, 2013 at 8:34 AM, Benjamin Peterson  
>>> wrote:
>>>> 2013/11/10 anatoly techtonik :
>>>>> http://hg.python.org/cpython/file/1ee45eb6aab9/Parser/Python.asdl
>>>>>
>>>>> In Assign(expr* targets, expr value), why the first argument is a list?
>>>>
>>>> x = y = 42
>>>
>>> Thanks.
>>>
>>> Speaking of this ASDL. `expr* targets` means that multiple entities of
>>> `expr` under the name 'targets' can be passed to Assign statement.
>>> Assign uses them as left value. But `expr` definition contains things
>>> that can not be used as left side assignment targets:
>>>
>>> expr = BoolOp(boolop op, expr* values)
>>>  | BinOp(expr left, operator op, expr right)
>>>  ...
>>>  | Str(string s) -- need to specify raw, unicode, etc?
>>>  | Bytes(bytes s)
>>>  | NameConstant(singleton value)
>>>  | Ellipsis
>>>
>>>  -- the following expression can appear in assignment context
>>>  | Attribute(expr value, identifier attr, expr_context ctx)
>>>  | Subscript(expr value, slice slice, expr_context ctx)
>>>  | Starred(expr value, expr_context ctx)
>>>  | Name(identifier id, expr_context ctx)
>>>  | List(expr* elts, expr_context ctx)
>>>  | Tuple(expr* elts, expr_context ctx)
>>>
>>> If I understand correctly, this is compiled into C struct definitions
>>> (Python-ast.c), and there is a code to traverse the structure, but
>>> where is code that validates that the structure is correct? Is it done
>>> on the first level - text file parsing, before ASDL is built? If so,
>>> then what is the role of this ADSL exactly that the first step is
>>> unable to solve?
>>
>> Only valid expression targets are allowed during AST construction. See
>> set_expr_context in ast.c.
>
> Oh my. Now there is also CST in addition to AST. This stuff -
> http://docs.python.org/devguide/ - badly needs diagrams about data
> transformation toolchain from Python source code to machine
> execution instructions. I'd like some pretty stuff, but raw blogdiag
> hack will do the job http://blockdiag.com/en/blockdiag/index.html
>
> There is no set_expr_context in my copy of CPython code, which
> seems to be some alpha of Python 3.4
>
>>> Is it possible to fix ADSL to move `expr` that are allowed in Assign
>>> into `expr` subset? What effect will it achieve? I mean - will ADSL
>>> compiler complain about wrong stuff on the left side, or it will still
>>> be a role of some other component. Which one?
>>
>> I'm not sure what you mean by an `expr` subset.
>
> Transform this:
>
> expr = BoolOp(boolop op, expr* values)
>  | BinOp(expr left, operator op, expr right)
>  ...
>  | Str(string s) -- need to specify raw, unicode, etc?
>  | Bytes(bytes s)
>  | NameConstant(singleton value)
>  | Ellipsis
>
>  -- the following expression can appear in assignment context
>  | Attribute(expr value, identifier attr, expr_context ctx)
>  | Subscript(expr value, slice slice, expr_context ctx)
>  | Starred(expr value, expr_context ctx)
>  | Name(identifier id, expr_context ctx)
>  | List(expr* elts, expr_context ctx)
>  | Tuple(expr* elts, expr_context ctx)
>
> to this:
>
> expr = BoolOp(boolop op, expr* values)
>  | BinOp(expr left, operator op, expr right)
>  ...
>  | Str(string s) -- need to specify raw, unicode, etc?
>  | Bytes(bytes s)
>  | NameConstant(singleton value)
>  | Ellipsis
>
>  -- the following expression can appear in assignment context
>  | expr_asgn
>
>  expr_asgn =
>Attribute(expr value, identifier attr, expr_context ctx)
>  | Subscript(expr value, slice slice, expr_context ctx)
>  | Starred(expr value, expr_context ctx)
>  | Name(identifier id, expr_context ctx)
>  | List(expr* elts, expr_context ctx)
>  | Tuple(expr* elts, expr_context ctx)

And also this:

  | Assign(expr* targets, expr value)

to this:

  | Assign(expr_asgn* targets, expr value)
___
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] Assign(expr* targets, expr value) - why targetS?

[anatoly techtonik]

On Fri, Nov 15, 2013 at 5:43 PM, Benjamin Peterson  wrote:
> 2013/11/15 anatoly techtonik :
>> On Tue, Nov 12, 2013 at 5:08 PM, Benjamin Peterson  
>> wrote:
>>> 2013/11/12 anatoly techtonik :
>>>> On Sun, Nov 10, 2013 at 8:34 AM, Benjamin Peterson  
>>>> wrote:
>>>>> 2013/11/10 anatoly techtonik :
>>>>>> http://hg.python.org/cpython/file/1ee45eb6aab9/Parser/Python.asdl
>>>>>>
>>>>>> In Assign(expr* targets, expr value), why the first argument is a list?
>>>>>
>>>>> x = y = 42
>>>>
>>>> Thanks.
>>>>
>>>> Speaking of this ASDL. `expr* targets` means that multiple entities of
>>>> `expr` under the name 'targets' can be passed to Assign statement.
>>>> Assign uses them as left value. But `expr` definition contains things
>>>> that can not be used as left side assignment targets:
>>>>
>>>> expr = BoolOp(boolop op, expr* values)
>>>>  | BinOp(expr left, operator op, expr right)
>>>>  ...
>>>>  | Str(string s) -- need to specify raw, unicode, etc?
>>>>  | Bytes(bytes s)
>>>>  | NameConstant(singleton value)
>>>>  | Ellipsis
>>>>
>>>>  -- the following expression can appear in assignment context
>>>>  | Attribute(expr value, identifier attr, expr_context ctx)
>>>>  | Subscript(expr value, slice slice, expr_context ctx)
>>>>  | Starred(expr value, expr_context ctx)
>>>>  | Name(identifier id, expr_context ctx)
>>>>  | List(expr* elts, expr_context ctx)
>>>>  | Tuple(expr* elts, expr_context ctx)
>>>>
>>>> If I understand correctly, this is compiled into C struct definitions
>>>> (Python-ast.c), and there is a code to traverse the structure, but
>>>> where is code that validates that the structure is correct? Is it done
>>>> on the first level - text file parsing, before ASDL is built? If so,
>>>> then what is the role of this ADSL exactly that the first step is
>>>> unable to solve?
>>>
>>> Only valid expression targets are allowed during AST construction. See
>>> set_expr_context in ast.c.
>>
>> Oh my. Now there is also CST in addition to AST. This stuff -
>> http://docs.python.org/devguide/ - badly needs diagrams about data
>> transformation toolchain from Python source code to machine
>> execution instructions. I'd like some pretty stuff, but raw blogdiag
>> hack will do the job http://blockdiag.com/en/blockdiag/index.html
>>
>> There is no set_expr_context in my copy of CPython code, which
>> seems to be some alpha of Python 3.4
>
> It's actually called set_context.

Ok. So what is the process?

 SOURCE --> TOKEN STREAM --> SENTENCE STREAM --> CST -->
--> AST --> BYTECODE

Is that right?

>>>> Is it possible to fix ADSL to move `expr` that are allowed in Assign
>>>> into `expr` subset? What effect will it achieve? I mean - will ADSL
>>>> compiler complain about wrong stuff on the left side, or it will still
>>>> be a role of some other component. Which one?
>>>
>>> I'm not sure what you mean by an `expr` subset.
>>
>> Transform this:
>>
>> expr = BoolOp(boolop op, expr* values)
>>  | BinOp(expr left, operator op, expr right)
>>  ...
>>  | Str(string s) -- need to specify raw, unicode, etc?
>>  | Bytes(bytes s)
>>  | NameConstant(singleton value)
>>  | Ellipsis
>>
>>  -- the following expression can appear in assignment context
>>  | Attribute(expr value, identifier attr, expr_context ctx)
>>  | Subscript(expr value, slice slice, expr_context ctx)
>>  | Starred(expr value, expr_context ctx)
>>  | Name(identifier id, expr_context ctx)
>>  | List(expr* elts, expr_context ctx)
>>  | Tuple(expr* elts, expr_context ctx)
>>
>> to this:
>>
>> expr = BoolOp(boolop op, expr* values)
>>  | BinOp(expr left, operator op, expr right)
>>  ...
>>  | Str(string s) -- need to specify raw, unicode, etc?
>>  | Bytes(bytes s)
>>  | NameConstant(singleton value)
>>  | Ellipsis
>>
>>  -- the following expression can appear in assignment context
>>  | expr_asgn
>>
>>

Re: [Python-Dev] Assign(expr* targets, expr value) - why targetS?

[anatoly techtonik]

On Fri, Nov 22, 2013 at 3:29 PM, Benjamin Peterson  wrote:
> 2013/11/22 anatoly techtonik :
>> On Fri, Nov 15, 2013 at 5:43 PM, Benjamin Peterson  
>> wrote:
>>> 2013/11/15 anatoly techtonik :
>>>> On Tue, Nov 12, 2013 at 5:08 PM, Benjamin Peterson  
>>>> wrote:
>>>>> 2013/11/12 anatoly techtonik :
>>>>>> On Sun, Nov 10, 2013 at 8:34 AM, Benjamin Peterson  
>>>>>> wrote:
>>>>>>> 2013/11/10 anatoly techtonik :
>>>>>>>> http://hg.python.org/cpython/file/1ee45eb6aab9/Parser/Python.asdl
>>>>>>>>
>>>>>>>> In Assign(expr* targets, expr value), why the first argument is a list?
>>>>>>>
>>>>>>> x = y = 42
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> Speaking of this ASDL. `expr* targets` means that multiple entities of
>>>>>> `expr` under the name 'targets' can be passed to Assign statement.
>>>>>> Assign uses them as left value. But `expr` definition contains things
>>>>>> that can not be used as left side assignment targets:
>>>>>>
>>>>>> expr = BoolOp(boolop op, expr* values)
>>>>>>  | BinOp(expr left, operator op, expr right)
>>>>>>  ...
>>>>>>  | Str(string s) -- need to specify raw, unicode, etc?
>>>>>>  | Bytes(bytes s)
>>>>>>  | NameConstant(singleton value)
>>>>>>  | Ellipsis
>>>>>>
>>>>>>  -- the following expression can appear in assignment context
>>>>>>  | Attribute(expr value, identifier attr, expr_context ctx)
>>>>>>  | Subscript(expr value, slice slice, expr_context ctx)
>>>>>>  | Starred(expr value, expr_context ctx)
>>>>>>  | Name(identifier id, expr_context ctx)
>>>>>>  | List(expr* elts, expr_context ctx)
>>>>>>  | Tuple(expr* elts, expr_context ctx)
>>>>>>
>>>>>> If I understand correctly, this is compiled into C struct definitions
>>>>>> (Python-ast.c), and there is a code to traverse the structure, but
>>>>>> where is code that validates that the structure is correct? Is it done
>>>>>> on the first level - text file parsing, before ASDL is built? If so,
>>>>>> then what is the role of this ADSL exactly that the first step is
>>>>>> unable to solve?
>>>>>
>>>>> Only valid expression targets are allowed during AST construction. See
>>>>> set_expr_context in ast.c.
>>>>
>>>> Oh my. Now there is also CST in addition to AST. This stuff -
>>>> http://docs.python.org/devguide/ - badly needs diagrams about data
>>>> transformation toolchain from Python source code to machine
>>>> execution instructions. I'd like some pretty stuff, but raw blogdiag
>>>> hack will do the job http://blockdiag.com/en/blockdiag/index.html
>>>>
>>>> There is no set_expr_context in my copy of CPython code, which
>>>> seems to be some alpha of Python 3.4
>>>
>>> It's actually called set_context.
>>
>> Ok. So what is the process?
>>
>>  SOURCE --> TOKEN STREAM --> SENTENCE STREAM --> CST -->
>> --> AST --> BYTECODE
>>
>> Is that right?
>
> I don't know what sentence stream is, but otherwise looks right.

I mean that when you have TOKENS, you need to validate that their
order is valid and throw errors to console if it is not. Like every sentence
should have certain word order to make sense, you won't be able to
construct CST from tokens that are placed in wrong order. Right?

Or is CST itself a tree of tokens, which position is validated when the
tree is transformed to AST?


FWIW, I've modified my astdump project to make it easy to explore
Python AST and experiment with it. This dataset shows how to create
coverage for AST transformations (visitors)
https://bitbucket.org/techtonik/astdump/src/tip/dataset/?at=default
___
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) now committed

[anatoly techtonik]

It was too fast. I didn't had a chance to send the comments.
--
anatoly t.


On Fri, Nov 22, 2013 at 7:44 PM, Antoine Pitrou  wrote:
>
> Hello,
>
> I've pushed pathlib to the repository. I'm hopeful there won't be
> new buildbot failures because of it, but still, there may be some
> platform-specific issues I'm unaware of.
>
> I hope our Release Manager is doing ok :-)
>
> Regards
>
> Antoine.
>
>
> ___
> 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/techtonik%40gmail.com
___
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) now committed

[anatoly techtonik]

I'd vote for a different perspective on path handling. For me the
pathlib is not the
good way to go. Especially with copying ill behaviour of old os.path functions.

We definitely need a "task force page" dedicated to "working with paths in
Python" to collaborate. ML + PEP with privileged write access is ineffective.

While I like the problem decomposition what I see in pathlib, I don't think it
supports the greatest power of Python that it allows you not to think about
cross-platform differences -
http://clanmills.com/files/dist/doc/cross_platform.html#python-batteries-included
I've got the impression that while using pathlib you should care about those.

I am +1 for iterating few more times to research best compromise between the
most simple possible and most user friendly interface (wart-free). But every
iteration should be historically accessible like in blog report, not like in
Mercurial PEP diff. There is still problem to dedicate time though.


--
anatoly t.


On Sat, Nov 23, 2013 at 4:32 PM, Serhiy Storchaka  wrote:
> 22.11.13 18:44, Antoine Pitrou написав(ла):
>
>> I've pushed pathlib to the repository. I'm hopeful there won't be
>> new buildbot failures because of it, but still, there may be some
>> platform-specific issues I'm unaware of.
>
>
> Congratuate Antoine!
>
> Does it means that issues #11344 (Add os.path.splitpath(path) function) [1]
> and #13968 (Support recursive globs) [2] have no chance? Both are ready for
> commit and waits for reviews almost a year. Are the os.path and glob modules
> deprecated now?
>
> [1] http://bugs.python.org/issue11344
> [2] http://bugs.python.org/issue13968
>
>
>
> ___
> 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/techtonik%40gmail.com
___
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] buildbot's are needlessly compiling -O0

[anatoly techtonik]

On Sun, Nov 24, 2013 at 12:43 PM, Nick Coghlan  wrote:
>
> On 24 Nov 2013 17:15, "Gregory P. Smith"  wrote:
>>
>> our buildbots are setup to configure --with-pydebug which also
>> unfortunately causes them to compile with -O0... this results in a python
>> binary that is excruciatingly slow and makes the entire test suite run take
>> a long time.
>>
>> given that nobody is ever going to run a gdb or another debugger on the
>> buildbot generated transient binaries themselves how about we speed all of
>> the buildbot's up by adding CFLAGS=-O2 to the configure command line?
>
> The main problem is that doing so would disable test_gdb. Humans don't run
> gdb on those binaries, but the test suite does.

Is there a danger that the code tested under GDB is not tested in
"natural environment" for pythons?
--
anatoly t.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] PEP process entry point and ill fated initiatives

[anatoly techtonik]

I wanted to help people who are trying to find out more
about PEP submission process by providing relevant
info (or a pointer) in README.rst that is located at the
root of PEPs repository. You can see it here.

https://bitbucket.org/rirror/peps

I filled this issue with b.p.o

http://bugs.python.org/issue19822

However, as you may see, I met some resistance,
which said me to discuss the matter here. So, I'd like
to discuss two things:

1. is my README.rst enhancement request is wrong?
2. what makes people close tickets without providing
arguments, but using stuff like "should"?

It is not the first stuff that I personally find discouraging,
which may be attributed to my reputation, but what's the
point in doing this?

The only logical explanation I find for resistance in this
particular case is that people in core Python
development don't take usability and user experience
matters seriously. Most of core development is about
systems, not about people, so everybody is scratching
own itches. I wish that usability and UX was given at
least some coverage in Python development regulations.
--
anatoly t.
___
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 process entry point and ill fated initiatives

[anatoly techtonik]

On Thu, Nov 28, 2013 at 9:39 PM, Guido van Rossum  wrote:
> Anatoly, the Python community is a lot more diverse than you think. "Pull
> requests" (whatever that means) are not the way to start a PEP. You should
> start by focusing on the contents, and the mechanics of editing it and
> getting it formatted properly are secondary. The process is explained in PEP
> one. Your bug report would have gotten a much better response if you had
> simply asked "what is the process, I can't figure it out from the repo's
> README" rather that (again) complaining that the core developers don't care.
> Offending people is not the way to get them to help you.

Sorry, I didn't mean to offend anyone. It never was my goal.

Everybody knows that I personally can easily find information about how to start
new PEP - like this one - http://www.python.org/dev/peps/pep-0001/
I am not sure it is _the entry point_ I am looking for, because it may
happen that
there is a more up-to-date chapter about this in devguide. That's why I didn't
paste any links - PEP list subscribers know a lot better about the
process than I
am. But the issue is - if my point of entry is PEP repo, and the first
thing I do is
reading the README, I expect it to contain the link to the PEP process, and this
link is missing. It is not that I can't figure out something, it is
that people need
more time than necessary to find required info, and the time is the
most valuable
resource.


Now there is a huge part about "community process vision", complains, analysis,
request to resume CLArification work, and generic stuff about experience. It is
not obligatory to read.

About ill fated initiatives. I don't like when people prematurely close tickets
without waiting for the mutual agreement that the problem is solved. Perhaps
trackers should have personal "agree/disagree/meh" flags to help other
people state their opinions, but until then the lack of time will
always lead to the
same communication problems. I value contributions people made for Python,
even if I am not expressive about it, I do realize that without all
these people it
won't be possible. I can only regret that people can't self-sustain
the feeling that
they are important and that they take offence instead.

Perhaps this offence is that makes them closing tickets without
waiting for reply.
Reply is not be required to close ticket for valid reason, but the
point of conflict
is that I don't like when tickets are prematurely closed under the reason of
"you. do it right" instead of "let's make it better".

Both "right" and "better" are subjective, but there is a big
difference. "better"
can be discussed, and "right" is not. I don't think it's ok. I understand that
people don't have time to waste in chit chatting, but so do I, and
everybody else
out there.

I am disrespectful to policies, that's right. I believe that policies need to be
revised every couple of years, but nobody do this. Rules that work for
folks that
were present at the time the consensus is reached need to be explained
to those who came later, and still you can't expect them to comply. Just
because they don't have choice, they may choose to ignore, and community
loses another contributor.

I again complain, because I see many things that don't move and it doesn't
make me happy. I can not be polite if I am not happy. From one side it's my
own problem and I know about. Another aspect is that I won't have motivation
to write if I am unhappy and polite - it is depressive. From the other
side there
is also a point of conflict that can not be ignored. People who signed CLA do
not understand my position that CLA is harmful. They think that if I didn't sign
it then I am just trolling and exclude me. I won't send patches until
CLA is clear
for every contributor and not like "common, just sign it, I am not a lawyer, but
they know it is good". This probably make people upset, and they try to "help"
you, so you have to maintain a sane amount of "dignity" to resist the pressure.
People afraid to accept patches even when I *explicitly* give my permission to
use them. I tired of writing patches that can not be accepted even with my
explicit permission - permission in which I understand what I am giving out. But
apparently there is something wrong with my permission - it is not incomplete,
because if something was missing - people would tell me about it. But people
don't understand what is missing. They say "you, do it right", "CLA is
the right"
way. I ask why, and there is silence. No, I've been given a lot of complicated
books about lawyership, stuff that was written before I was born. I
don't get it.

That's my ill fated initiative to clarify the CLA and make Python contribution
process free from FUD. People "do it right" and force other people to "do it
right" as I see it. That's a natural process, but it can be constructive if the
meaning of what is "right" is discussed and changed if necessary. Otherwise
Python development becomes an exclusive privileg

Re: [Python-Dev] Python3 "complexity"

[anatoly techtonik]

On Thu, Jan 9, 2014 at 10:00 AM, Mark Lawrence  wrote:
> On 09/01/2014 06:50, Lennart Regebro wrote:
>>
>> On Thu, Jan 9, 2014 at 1:07 AM, Ben Finney 
>> wrote:
>>>
>>> Kristján Valur Jónsson  writes:
>>>
 Believe it or not, sometimes you really don't care about encodings.
 Sometimes you just want to parse text files.
>>>
>>>
>>> Files don't contain text, they contain bytes. Bytes only become text
>>> when filtered through the correct encoding.
>>
>>
>> To be honest, you can define text as "A stream of bytes that are split
>> up in lines separated by a linefeed", and do some basic text
>> processing like that. Just very *basic*, but still. Replacing
>> characters. Extracting certain lines etc.
>>
>> This is harder in Python 3, as bytes does not have all the
>> functionality strings has, like formatting. This can probably be fixed
>> in Python 3.5, if the relevant PEP gets finished.
>>
>> For the battery analogy, that's like saying:
>>
>> "I want a battery."
>>
>> "What kind?"
>>
>> "It doesn't matter, as long as it's over 5V."
>>
>> //Lennart
>>
>
> "That Python 3 battery you sold me blew up when I tried using it".
>
> "We've been telling you for years that could happen".
>
> "I didn't think you actually meant it".

  "These new nuclear cells are awesome! But you stop from from
leaking on their users?"

A1: "The nuclear power is radioactive. Accept it."

A2: "This is the basic stdlib container. You're supposed to protect yourself."

A3: "The world is changing. Everybody should learn nuclear fission to
use things properly."

  "..."

and while we are at it, if the battery became more advanced, there is
no reason to
strip off simple default interface. This interface is not an abstract
discussion here,
but a real user experience study (I am going to spread UX virus),
which starts with:

  1. expectations
  2. experience
  3. outcomes

and progressively iterate over 2 to get 3 matching 1 as close as
possibly, without
trying to change 1. 1 is equal to changing people - it is simple and
natural solution
that people practicing every day on children and subordinates. The
only problem is
that it is ineffective, hard and useless activity in open source
environment, because
most people by the nature of their neural network processes become conservative
with ages. That's why people invented forks. However, for the encoding problem,
there are some good default solutions. You'll have choose between different
interests anyway, but here it is:

  1. always open() text files in UTF-8 by default
  2. introduce autodetect mode to open functions
 1. read and transform on the fly, maintaining a buffer that
stores original bytes
 and their mapping to letters. The mapping is updated as bytes frequency
 changes. When the buffer is full, you have the best candidate.
  3. provide sane error messages
 1. messages that users do actually understand
 2. messages that tell how to fix the problem

If interface becomes more complicated - the last thing you should do is to leave
user 1:1 with interface problems.

And to conclude, I am not saying that people should not learn about unicode,
but the learning curve should not be as steep as Python 3 demands 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] cpython (3.3): Update Sphinx toolchain.

[anatoly techtonik]

And cross-platform automation tools in Python instead of make
https://bitbucket.org/birkenfeld/sphinx/issue/456/makepy-command-script
--
anatoly t.


On Sun, Jan 12, 2014 at 11:12 AM, INADA Naoki  wrote:
> What about using venv and pip instead of svn?
>
>
> On Sun, Jan 12, 2014 at 4:12 PM, Georg Brandl  wrote:
>>
>> Am 11.01.2014 21:11, schrieb Terry Reedy:
>> > On 1/11/2014 2:04 PM, georg.brandl wrote:
>> >> http://hg.python.org/cpython/rev/87bdee4d633a
>> >> changeset:   88413:87bdee4d633a
>> >> branch:  3.3
>> >> parent:  88410:05e84d3ecd1e
>> >> user:Georg Brandl 
>> >> date:Sat Jan 11 20:04:19 2014 +0100
>> >> summary:
>> >>Update Sphinx toolchain.
>> >>
>> >> files:
>> >>Doc/Makefile |  8 
>> >>1 files changed, 4 insertions(+), 4 deletions(-)
>> >>
>> >>
>> >> diff --git a/Doc/Makefile b/Doc/Makefile
>> >> --- a/Doc/Makefile
>> >> +++ b/Doc/Makefile
>> >> @@ -41,19 +41,19 @@
>> >>   checkout:
>> >>  @if [ ! -d tools/sphinx ]; then \
>> >>echo "Checking out Sphinx..."; \
>> >> -  svn checkout $(SVNROOT)/external/Sphinx-1.0.7/sphinx
>> >> tools/sphinx; \
>> >> +  svn checkout $(SVNROOT)/external/Sphinx-1.2/sphinx tools/sphinx;
>> >> \
>> >>  fi
>> >
>> > Doc/make.bat needs to be similarly updated.
>>
>> Indeed, thanks for the reminder.
>>
>> Georg
>>
>> ___
>> 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/songofacandy%40gmail.com
>
>
>
>
> --
> INADA Naoki  
>
> ___
> 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/techtonik%40gmail.com
>
___
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] cpython (3.3): Update Sphinx toolchain.

[anatoly techtonik]

That's cool, but historical heritage makes the make argument
somewhat confusing for new users. The immediate question I
can sense is "What is the difference between build and make?"

To make (this word again) the critics constructive, let me pass
some ideas about ideal user experience as I see it.

--[installation]--
1   I install Sphinx. Two scenarios.
   1.1   I am not a Python user - use installer
  1.1.1   Installer should obviously install Python
  1.1.2   And install sphinx command
  1.1.3   And add sphinx to PATH
   1.2   I am a Python user - use pip
  1.2.1   pip should not alter my PATH (for virtualenv)

--[usage]--
2   Two scenarios
   2.1   sphinx as a system command from PATH
   2.2   "python -m sphinx" for current virtualenv / test config

--[user experience]--
3   These two invocations are equal
> sphinx
> python -m sphinx

4. They give the following ouput
>
Sphinx 1.2 Documentation Generator

Commands:

   build   build documentation
   init start new project [also quickstart]
   make  helper for common build commands

Use "sphinx -h command" or "sphinx command --help" for details


I am not using sphinx ATM otherwise I'd spent more time to
design ideal command set to get rid of build/make duality, but
it should work ok.

Actually "sphinx" is a new command, so you may rethink the
syntax for "build" arguments to contain "html" instead of dir names,
and move dir names into parameters, because it is how it is most
often used.

--
anatoly t.


On Sun, Jan 12, 2014 at 4:53 PM, Georg Brandl  wrote:
> That's also planned, see 
> https://bitbucket.org/birkenfeld/sphinx-new-make-mode/.
>
> Georg
>
> Am 12.01.2014 09:49, schrieb anatoly techtonik:
>> And cross-platform automation tools in Python instead of make
>> https://bitbucket.org/birkenfeld/sphinx/issue/456/makepy-command-script
>> --
>> anatoly t.
>>
>>
>> On Sun, Jan 12, 2014 at 11:12 AM, INADA Naoki  wrote:
>>> What about using venv and pip instead of svn?
>
>
> ___
> 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/techtonik%40gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] PyPI offline, status is ok

[anatoly techtonik]

http://status.python.org/ shows all green

https://pypi.python.org/pypi/gazest shows

Error 503 backend read error

backend read error

Guru Meditation:

XID: 2792709923



Varnish cache server


https://pypi.python.org/pypi/ shows

XID: 4199593736


-- 
anatoly t.
___
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] PyPI offline, status is ok

[anatoly techtonik]

On Mon, Feb 10, 2014 at 1:42 PM, Chris Angelico  wrote:
> On Mon, Feb 10, 2014 at 5:23 PM, anatoly techtonik  
> wrote:
>> http://status.python.org/ shows all green
>>
>> https://pypi.python.org/pypi/gazest shows
>>
>> Error 503 backend read error
>>
>> backend read error
>>
>> Guru Meditation:
>>
>> XID: 2792709923
>
> Working for me. But then, your email only just came through, and it's
> dated four hours ago, so maybe python-dev was also having trouble. Or
> maybe your ISP was having trouble. Hard to say now.

ISP for sure won't run Varnish, which is enabled for Python Warehouse here:
https://github.com/python/psf-chef/blob/14bbebdbbc4f7ccc65e0478458cab433594f2cfa/cookbooks/psf-pypi/recipes/warehouse.rb
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Dead code in json/encoder?

[anatoly techtonik]

It looks like _one_shot parameter is always called with True argument
and unused. What is the purpose of it?

https://github.com/python/cpython/blob/de1b33f6e6071816a1fc52cd5f0c6cd47d704251/Lib/json/encoder.py#L239-L249

-- 
anatoly t.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] New absolute __file__ in Python 3.4

[anatoly techtonik]

https://docs.python.org/3.4/whatsnew/3.4.html#other-language-changes

1. Is this absolute name with symlinks resolved?
2. Why there is a special case for __main__?
(i.e. Special cases aren't special enough to break the rules.)
3. What link should I click in Python reference to read
about standard globals like __file__ and this change?
https://docs.python.org/3.4/library/index.html
something like this in PHP
http://www.php.net/manual/en/language.constants.predefined.php
-- 
anatoly t.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Python usability study (Was: Language Summit notes)

[anatoly techtonik]

On Thu, Apr 10, 2014 at 2:24 PM, Kushal Das  wrote:
> Glyph wants a PSF fund to a usability study on Python. There were a
> few other suggestion on PSF support for tooling development.

+2 on initiative

-- 
anatoly t.
___
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 2.7.7. on Windows

[anatoly techtonik]

On Mon, Apr 28, 2014 at 11:07 PM, Mike Miller  wrote:
> On 04/29/2014 05:12 AM, Steve Dower wrote:
>>
>> This would be an incredibly painful change that would surprise and hurt a
>> lot of
>> people.
>
>
> Hi, I think "incredibly painful" is overstating the case a bit. ;)  We're
> talking about an installer default, a setting that would still be changeable
> as it always has, that by definition only will affect brand new installs.

You don't take into account many tutorials and internal docs that make the
job of new users easier by using this default. Human processes will be
broken, newbies will suffer.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] subprocess shell=True on Windows doesn't escape ^ character

[anatoly techtonik]

I am banned from tracker, so I post the bug here:

Normal Windows behavior:

  >hg status --rev ".^1"
  M mercurial\commands.py
  ? pysptest.py

  >hg status --rev .^1
  abort: unknown revision '.1'!

So, ^ is an escape character. See
http://www.tomshardware.co.uk/forum/35565-45-when-special-command-line


But subprocess doesn't escape it, making cross-platform command fail on
Windows.

---[cut pysptest.py]--
import subprocess as sp

# this fails with
# abort: unknown revision '.1'!
cmd = ['hg', 'status', '--rev', '.^1']
# this works
#cmd = 'hg status --rev ".^1"'
# this works too
#cmd = ['hg', 'status', '--rev', '.^^1']

try:
  print sp.check_output(cmd, stderr=sp.STDOUT, shell=True)
except Exception as e:
  print e.output
--

-- 
anatoly t.
___
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] subprocess shell=True on Windows doesn't escape ^ character

[anatoly techtonik]

On Thu, Jun 12, 2014 at 1:30 AM, Chris Angelico  wrote:

> Why pass shell=True when executing a single
> command? I don't get it.
>

I don't know about Linux, but on Windows programs are not directly
available as /usr/bin/python, so you need to find command in PATH
directories. Passing shell=True makes this lookup done by shell and not
manually.
___
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] subprocess shell=True on Windows doesn't escape ^ character

[anatoly techtonik]

On Thu, Jun 12, 2014 at 1:30 AM, Chris Angelico  wrote:

> On Thu, Jun 12, 2014 at 7:58 AM, Ryan  wrote:
> > In all seriousness, to me this is obvious. When you pass a command to the
> > shell, naturally, certain details are shell-specific.
>

On Windows cmd.exe is used by default:
http://hg.python.org/cpython/file/38a325c84564/Lib/subprocess.py#l1108
so it makes sense to make default behavior cross-platform.


>  > -1. Bad idea. Very bad idea. If you want the ^ to be escaped, do it
> > yourself. Or better yet, don't pass shell=True.
>
> Definitely the latter. Why pass shell=True when executing a single
> command? I don't get it.
>

This is a complete use case using Rietveld upload script:
http://techtonik.rainforce.org/2013/07/code-review-with-rietveld-and-mercurial.html

I am interested to know how to modify upload script without kludges:
https://code.google.com/p/rietveld/source/browse/upload.py#1056
I expect many people are facing with the same problem trying to wrap
Git and HG with Python scripts.
-- 
anatoly t.
___
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] subprocess shell=True on Windows doesn't escape ^ character

[anatoly techtonik]

On Thu, Jun 12, 2014 at 2:00 AM, R. David Murray 
wrote:

> Also notice that using a list with shell=True is using the API
> incorrectly.  It wouldn't even work on Linux, so that torpedoes
> the cross-platform concern already :)
>
> This kind of confusion is why I opened http://bugs.python.org/issue7839.


I thought exactly about that. Usually separate arguments are used to avoid
problems with escaping of quotes and other stuff.

I'd deprecate subprocess and split it into separate modules. One is about
shell execution and another one is for secure process control.

shell execution module then could build on top of process control and be
insecure by design.
___
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] subprocess shell=True on Windows doesn't escape ^ character

[anatoly techtonik]

On Fri, Jun 13, 2014 at 2:55 AM, Ryan Gonzalez  wrote:

> SHELLS ARE NOT CROSS-PLATFORM Seriously, there are going to be
> differences. If you really must:
>
> escape = lambda s: s.replace('^', '^^') if os.name == 'nt' else s
>

It is not about generic shell problem, it is about specific behavior that
on Windows Python already uses cmd.exe shell hardcoded in its sources. So
for crossplatform behavior on Windows, it should escape symbols on command
passed to cmd.exe that are special to this shell to avoid breaking Python
scripts. What you propose is a bad workaround, because it assumes that all
Python users who use subprocess to execute hg or git should possess apriori
knowledge about default subprocess behaviour with default shell on Windows
and implement workaround for that.
-- 
anatoly t.
___
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] subprocess shell=True on Windows doesn't escape ^ character

[anatoly techtonik]

On Fri, Jun 13, 2014 at 5:11 AM, Nikolaus Rath  wrote:

> "R. David Murray"  writes:
> > Also notice that using a list with shell=True is using the API
> > incorrectly.  It wouldn't even work on Linux, so that torpedoes
> > the cross-platform concern already :)
> >
> > This kind of confusion is why I opened http://bugs.python.org/issue7839.
>
> Can someone describe an use case where shell=True actually makes sense
> at all?
>

You need to write a wrapper script to automate several user commands. It is
quite common to use shell pipe redirection for joining many utils and calls
together than to rewrite data pipes in Python.
___
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] subprocess shell=True on Windows doesn't escape ^ character

[anatoly techtonik]

On Thu, Jun 12, 2014 at 5:12 AM, Chris Angelico  wrote:

> On Thu, Jun 12, 2014 at 12:07 PM, Chris Angelico  wrote:
> > ISTM what you want is not shell=True, but a separate function that
> > follows the system policy for translating a command name into a
> > path-to-binary. That's something that, AFAIK, doesn't currently exist
> > in the Python 2 stdlib, but Python 3 has shutil.which(). If there's a
> > PyPI backport of that for Py2, you should be able to use that to
> > figure out the command name, and then avoid shell=False.
>
> Huh. Next time, Chris, search the web before you post. Via a
> StackOverflow post, learned about distutils.spawn.find_executable().
>

I remember I even wrote a patch for it, but I forgot about it already.
Still feels like a hack that is difficult to find and understand that you
need really it. In Rietveld case it won't work, because upload.py script
allows user to specify arbitrary diff command to send change for
review.
___
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 Language Summit at PyCon: Agenda

[anatoly techtonik]

On Wed, Feb 27, 2013 at 7:51 PM, Michael Foord wrote:

> Hello all,
>
> PyCon, and the Python Language Summit, is nearly upon us. We have a good
> number of people confirmed to attend. If you are intending to come to the
> language summit but haven't let me know please do so.
>
> The agenda of topics for discussion so far includes the following:
>
> * A report on pypy status - Maciej and Armin
> * Jython and IronPython status reports - Dino / Frank
> * Packaging (Doug Hellmann and Monty Taylor at least)
> * Cleaning up interpreter initialisation (both in hopes of finding areas
>   to rationalise and hence speed things up, as well as making things
>   more embedding friendly). Nick Coghlan
> * Adding new async capabilities to the standard library (Guido)
> * cffi and the standard library - Maciej
> * flufl.enum and the standard library - Barry Warsaw
> * The argument clinic - Larry Hastings
>
> If you have other items you'd like to discuss please let me know and I can
> add them to the agenda.
>

I won't be able to visit, so this PyCon promises to be all good nice and
relaxing for everybody. =)
But here is some things that can spice up the meeting in case it becomes
boring.

* poor introspection capabilities
  * if you pause the code - what kind of data you'd like to be available?
  * magical locals() dict that breaks the rules
  * execution frames that lose information present in original source
(such as function vs method and probably others)
  * as an exercise - try to build a scroller for a running Python script
* it is impossible for Python 2 and probably for Python 3 as well

* visibility issues with language development
  * physically split the information flow about work being done on
interpreter and stdlib
  * split the information about stdlib development by modules
* describe modules composing in stdlib in formal way
  https://bitbucket.org/techtonik/python-stdlib
  * build a roadmap by module (join personal wishlist from involved people)
  * external people can not join teams dedicated only to several modules
people are interested in

* IPython and PyPy as a distraction for people who could improve core
language and stdlib here

* security by obscurity in legal position of PSF towards contributors
  https://code.google.com/legal/individual-cla-v1.0.html
   vs
  http://www.python.org/psf/contrib/contrib-form/ +
http://www.samurajdata.se/opensource/mirror/licenses/afl-2.1.php
  or
  http://www.python.org/psf/contrib/contrib-form/ +
http://opensource.org/licenses/apache2.0.php
   and why PSF doesn't comply the 4. Redistribution clause from Apache 2.0
license

* how to get more pictures and less text for reference, especially for
internals
* user story approach for writing PEPs

Can only wish to have a constructive PyCon with great results.
Bye.
-- 
anatoly t.
___
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] Fwd: Issue 1229 in nativeclient: Get Python to work under Native Client

[anatoly techtonik]

Does Python build system support cross-compiling? NaCl projects seems to
have problem with that. Just thought you might be interested to know about
it.



-- Forwarded message --
From: 
Date: Tue, Jul 16, 2013 at 9:24 PM
Subject: Re: Issue 1229 in nativeclient: Get Python to work under Native
Client
To: techto...@gmail.com


Updates:
Status: Fixed

Comment #8 on issue 1229 by mseab...@chromium.org: Get Python to work under
Native Client
http://code.google.com/p/**nativeclient/issues/detail?id=**1229

This is done in naclports.  Sam Clegg added initial support for building
against nacl-glibc in https://code.google.com/p/**
naclports/source/detail?r=802
.

Sam found a way to work around the Python build's lack of support for
cross-compiling.  The workaround is to build a native "pgen" first and
inject it into the later cross-build.

Building Python with nacl-newlib and PNaCl is a work in progress:
https://codereview.chromium.**org/18112024/
___
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] TransformDict (PEP 455) Naming

[anatoly techtonik]

Does anybody know if http://vote.python.org is already operational?

I decided to start a separate thread for TransformDict name, because I
want to change it.
Current implementation of PEP 455 only touches dictionary keys and it
is more narrow than the name suggests. I'd reserve TransformDict name
for something that is used to transform some other data. For my data
transformation theory I have an idea of mapping with annotated fields
that is used to change the names of some source data structure to
target data structure, converting types and applying custom rules on
the way. This is a different, but more intuitive application of such
name.

Name for the PEP 455 should be less abstract, more specialized. Which
transform? What is transformed? Where the transformation is taking
place? How it is going to be used? Why do you need a generalized
structure?

In PEP 455 I see two use cases only.
1. Case-insensitive keys.
  dictik()  - dictionary with insensitive keys
2. Identity dict.
  dictik()  - dictionary with implicit keys

The generic name for collections entry can be VagueKeysDict() or
DynamicKeysDict() or DynKeyDict(). The name should tell what's going
on with the type to people completely unfamiliar with concept.
OrderedDict() is a good name - dict with ordered entries, NamedTuple()
is so-so - tuple that has a name, but also ok. TransformDict() is just
too generic and doesn't tell anything - something is transformed, or
dict somehow transformed, or dict for transform. There should be a
better name.

--
anatoly t.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] PEP 453 (pip bootstrap) TL;DR and Usage Scenario

[anatoly techtonik]

On Mon, Sep 23, 2013 at 2:15 PM, Nick Coghlan  wrote:
> With the last round of updates, I believe PEP 453 is ready for
> Martin's pronouncement.
>
> HTML: http://www.python.org/dev/peps/pep-0453/
> Major diffs: http://hg.python.org/peps/rev/b2993450b32a

I'd enjoy concise PEP texts, but it is extremely hard to write one, so
is it possible to at least add a TL;DR chapter that just shows the
concept in 15 seconds without all the gory details? What is the
entrypoint in the bootstrap process and knowledge requirements for the
user?

For the same sake, is it possible to include real world usage scenario
as a code paste example of user session. For instance:

   # --- 001: user reads install instruction on  site
   # 'pip install '

   # user executes 'pip install ' on Windows
   > pip install 
   'pip' is not recognized as an internal or external command,
   operable program or batch file.
   # user .. ? [ ]

   # user executes 'pip install ' on Ubuntu
   $ pip install 
   The program 'pip' is currently not installed. You can install it by typing:
   sudo apt-get install pip
   $ sudo apt-get install pip
   # (user has sudo - done)
   # user doesn't have sudo, command fails
   # user .. ? [ ]

   # --- 002: user reads install instruction on  site
   # 'python -m pip install '

   $ python -m pip install 
   /usr/bin/python: No module named pip
   # user .. ? [ ]

-- 
anatoly t.
___
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] Adding support to curses library

[anatoly techtonik]

Please note that there is a pending change that will introduce curses
module on Windows in http://bugs.python.org/issue2889  I would really
like to see the patch in the issue integrated before it became invalid
due to other patches to test curses on Windows.

On Wed, Feb 25, 2009 at 5:34 PM, A.M. Kuchling  wrote:
> On Wed, Feb 25, 2009 at 06:30:06AM -0800, Heracles wrote:
>> is commented back in it does fail. I am not sure exactly how a debugger will
>> help in this case since the color_set call goes directly to the ncurses
>> library.  If in fact that the issue is the ncurses library then it seems
>> that there is no feasible solution until that library is fixed, in which
>> case this patch is sort of useless.
> ...
>> erg = color_set(color_pair_number, NULL); // Debating on forcing null
>
> What is color_pair_number in the C code?  If it's some incorrect value
> (-1?  255?), maybe ncurses is indexing off an array and crashing.
>
> This is why a debugger might help; you could run the test program
> until the crash and then print out the values of the relevant
> variables.  e.g. is stdscr set to a non-NULL value?  There might be a
> debugging version of ncurses that will let you look at the variables
> inside the ncurses code, which may make the problem clear.
>
> --amk
>
> ___
> 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/techtonik%40gmail.com
>



-- 
--anatoly t.
___
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] Pybots link obsolete?

[anatoly techtonik]

Still actual.

On Wed, Jan 7, 2009 at 5:54 PM, Antoine Pitrou  wrote:
> Hello,
>
> In http://www.python.org/dev/buildbot/, there's a link suggesting to visit the
> pybots Web site for more information. However, http://www.pybots.org/ just 
> says
> "Nothing here #".
>
> 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/techtonik%40gmail.com
>



-- 
--anatoly t.
___
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 wins Linux New Media Award for Best Open Source Programming Language

[anatoly techtonik]

On Sat, Mar 7, 2009 at 9:32 AM, Lie Ryan  wrote:

 The prize was Martin von Löwis of the Python Foundation on behalf of the
 Python community itself.
>>>
>>> This is a funny translation from German-to-English. :-)
>>>
>>> But yeah, a good one and the prize was presented by Klaus Knopper of
>>> Knoppix.
>>>
>>> Congratulations!
>>
>> Actually, the prize went to "Python", not to me, and not to the PSF. So
>> congratulations to you as well!
>
> The (translated) article says that YOU are the prize? WOW.
>
> Ummm... better not to use automatic translator for anything mission
> critical.
>

Congratulations! There is already a proper English version of press
release at 
http://www.linux-magazine.com/online/news/cebit_2009_openstreetmap_wins_two_linux_new_media_awards
so new link can probably be changed. The article still doesn't mention
competitors.

-- 
--anatoly t.
___
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] version compare function into main lib

[anatoly techtonik]

Greetings,

Correct me if I wrong, but shouldn't Python include function for
version comparisons?

The problem of splitting a string like "10.3.40-beta" into tuple for
cmp() seems to be dead simple, but the code gets bulky with excepting
errors arised from converting resulting strings for arithmetic
comparison. No wonder people advise to use ready distutils.version
module, but that's not good to introduce such dependency for main
program logic.

What do you think about adding cmpversions(first, second,
strict=false) based on distutils into main lib?
Will it be more appropriate to isolate the function into "versions" module?
Should it be rewritten to remove re dependency in this case?


Distutils version comparisons:
http://svn.python.org/view/python/branches/release26-maint/Lib/distutils/version.py?view=markup

--anatoly t.
___
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] os.defpath for Windows

[anatoly techtonik]

Hi,

I've added the issue to tracker. http://bugs.python.org/issue5717

--anatoly t.

On Sun, Dec 21, 2008 at 12:19 PM, Yinon Ehrlich  wrote:
> Hi,
>
> just saw that os.defpath for Windows is defined as
>        Lib/ntpath.py:30:defpath = '.;C:\\bin'
>
> Most Windows machines I saw has no c:\bin directory.
>
> Any reason why it was defined this way ?
> Thanks,
>        Yinon
> ___
> 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/techtonik%40gmail.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

[Python-Dev] Roundup keywords for bug tracking

[anatoly techtonik]

It is impossible to edit roundup keywords and this takes away the
flexibility in selecting bugs related to a module/function/test or
some other aspect of development. For example, I need to gather all
subprocess bugs in one query and things that won't be fixed in
deprecated os.popen() into another. In Trac I would use "subprocess"
and "os.popen" keywords. On ohloh I would add similar tags (if bugs
were software) without, but I can't do anything about Python roundup.
Is there any reason for such restriction?

--anatoly t.
___
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] Roundup keywords for bug tracking

[anatoly techtonik]

On Sat, Jun 6, 2009 at 4:07 AM, Daniel Diniz  wrote:
> anatoly techtonik wrote:
>>
>> It is impossible to edit roundup keywords and this takes away the
>> flexibility in selecting bugs related to a module/function/test or
>> some other aspect of development. For example, I need to gather all
>> subprocess bugs in one query and things that won't be fixed in
>> deprecated os.popen() into another. In Trac I would use "subprocess"
>> and "os.popen" keywords. On ohloh I would add similar tags (if bugs
>> were software) without, but I can't do anything about Python roundup.
>> Is there any reason for such restriction?
>
> Well, keywords are used as a very restricted set of tags, so only
> users in the Developer group can create them. We've discussed free
> form issue tags that any user can create or edit in #python-dev and
> tracker-discuss[0]. I'm pretty sure they'd cover your use-case. I've
> submitted a patch to Rietveld[1], but it seems I never filled it in
> the meta-tracker, oopsie.

>From [0] discussion it seems that tags are planned to be a replacement
for component or keywords field, but in my vision they should be just
tags that doesn't have any specific meaning or administration
interface. Autocomplete with ajax lookup is nice, but no drop-down
lists etc.

I made some comments in Rietveld at [1], but was unable to test it
live, because [2] is offline.

> If you (or anyone else) want to test-drive the tags feature, I can
> create an account in the experimental tracker[2] (which needs some
> attention anyway). I should be able to submit the patch to the
> meta-tracker during the weekend.

Hope this went well. I would definitely like to see how far this
feature from how I imagine it, but b.p.o. deployment could be a better
alternative for a real testing.

> Also, if you would like to bookmark arbitrary sets of issues, the
> bookmarklet and form in http://static.bot.bio.br/tool.html may be of
> help. You can paste the ids into the search page's ID field and create
> a query for a given (static) set of issues.

Seems like it can come in handy. Thanks.

-- 
anatoly t.
___
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 2.7 and 3.2

[anatoly techtonik]

On Sun, Jun 7, 2009 at 6:21 AM, Terry Reedy  wrote:
>
> I have thought that 2.7 was now to come out instead with 3.2 and would
> include backported 3.2 new features.  Others expect 2.7 to come out soon
> after 3.1 and to only contain new 3.1 features.  So Guido or someone, please
> clarify: is 2.7 to be the counterpart of 3.1 or 3.2?

Just my 0.02 cents, but struggling with all warts of 2.5 subprocessing
in Windows I would vote for more time for stabilizating things - not
adding new features. Long awaited subprocess as replacement for
os.popen() AFAIK is still incapable to asynchronously communicate with
spawned processes on Windows. I would call this feature as critical
even on 2.6  As a release testcase - try porting pyexpect module to
this platform. Absence of native curses/console/readline module also
makes Python one-way unix shell language while many users expect it to
be crossplatform.

-- 
anatoly t.
___
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 2.7 and 3.2

[anatoly techtonik]

On Mon, Jun 8, 2009 at 11:01 PM, "Martin v. Löwis"  wrote:
>
> I am not quite sure whether you are for new features or not. Your
> first sentence ("vote for ... not adding new features") seems to
> suggest that you would not like to see new features, and your last
> sentence ("absence of native curses/console/readline module")
> suggests that you *do* want to see new features (namely, a native
> curses module, and a native readline module).
>
> Which one is it?

I would like to see new features in Python, but only if they are
cross-platform. Unfortunately, I do not possess C skills to make this
happen, nor do I have deep understanding of Microsoft Visual Studio
.project files to port Makefiles and GCC options even when codebase is
available for windows.

The level to make a contribution in this case is too high. The lack of
free time makes it impossible to close the gap in one step leaving
remnants of work-in-process that will make it harder to continue in
future than to start from scratch.

Perhaps the necessity to make it in one huge step could be compensated
by incremental solution approach and development process if there was
obvious centralized place to organize efforts AND provide clear
visibility into progress made so far, initial plan, plan deviation and
current status. Mailing lists are good for discussions, but that's all
- information becomes outdated, text-too-much, no prompt reply often
stops the progress. Perhaps I shift my problem from lack-of-skill into
lack-of-tools direction, but being amazed by efforts people put into
supporting this mailing list I most of the time unable to reply to
emails I get mostly because replies require time for testing and
proving facts.

There is no definite proposal to solve problems of enabling OpenID or
SSO for python.org, of porting curses to windows, of testing
subprocessing etc., but there is an idea that some things could be
given more visibility AND priority to allow people to see the big
picture and focus on outstanding problems. Even though most people
here know about big-things-to-fix, these things doesn't standout from
the pile of issues in roundup.

The thing I miss the most is ability to gather all information
relevant to one problem in one place. This includes timeline with
commits, branches, relevant issues, issue updates, relevant wiki
edits, current focus URLs, _filtered_ threads and refactored comments.
The problem is to ensure that this information is up to date and
provide easy way/instruction how to bring it up to date in case
something is broken. It is not necessary to meet the bus to experience
the effect of bus factor.

-- 
anatoly t.
___
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] Roundup dependency tree changes

[anatoly techtonik]

Hello,

How about allowing all authenticated users update dependency field in
Python tracker?

http://bugs.python.org/iss...@sort0=dependencies&@sortdir0=on&@sort1=&@group0=priority&@group1=&@columns=title,id,activity,dependencies,status&@pagesize=150&@startwith=0

Looks like developers with access don't have enough time to track
issue dependencies.

--anatoly t.
___
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] IDLE as default Python editor (Was: [pygame] Python IDE for windoz)

[anatoly techtonik]

Hello,

Quite an interesting question recently popped up in pygame community
that I'd like to ask to Python developers.

How many of you use IDLE?
What's wrong with it?

>From my side I like the idea of having default Python editor that is
small, fast, convenient and extensible/embeddable. IDLE is small and
fast, but I feel really uncomfortable with its. The worst thing - I
can't change it. Does anybody else feel the same to think if we could
replace IDLE with something more maintainable by providing Scintilla
bindings, for example?

Regards,
-- 
anatoly t.



On Sat, Oct 10, 2009 at 8:15 PM, RB[0]  wrote:
> Most? people just don't like it - personally it's all I use, Windows or
> otherwise...
>
> On Sat, Oct 10, 2009 at 12:23 PM, Kris Schnee  wrote:
>>
>> What's wrong with the built-in editor, IDLE?
>
>
___
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] Replacing IDLE

[anatoly techtonik]

On Tue, Nov 10, 2009 at 12:10 AM, "Martin v. Löwis"  wrote:
>>
>> Anatoly's question is actually a fair one for python-dev - we're the
>> ones that *ship* Idle, so it is legitimate to ask our reasons for
>> continuing to do so.
>
> OTOH, the second (or, rather, third) question (does anybody think it
> should be replaced) is indeed on-topic for python-dev.

That is the exact question I have in my mind. Sorry for not being able
to state it clearly. I'll be more straightforward next time.

> I didn't really answer that question before, so I do now: I have not
> personally plans to replace it, and I'm skeptical wrt. anybody else's
> plans unless there is specific code in existence that IDLE could be
> replaced *with*.

There are a lot of Python editors. It is unlikely that they implement
all IDLE features, but I believe that 20% of IDLE features that is
used by 80% of users are guaranteed by any editor out of the box.
Assuming that they are more extensible than IDLE anyway. (I would say
"perfection is achieved when there is nothing more to add...", but I
promised to be straightforward).

If we filter list of http://wiki.python.org/moin/PythonEditors by
language/license/framework, we will be able to see if there is any
suitable open source Python code to replace IDLE's.


Then there will be another issue - all editors are based upon some
frameworks - I didn't see any popular cross-platform GUI toolkits in
Python, so we will inevitably face the need to replace Tkinter with
other default GUI toolkit.

Should we place an editor first and combine the list a of unique
features of IDLE that we (as developers) will surely miss  OR  should
we think what GUI framework will be more beneficial for Python users
if shipped by default (keeping in mind that we might have to add
missing features to whatever editor we choose later)?

-- 
anatoly t.
___
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] Replacing IDLE

[anatoly techtonik]

On Tue, Nov 10, 2009 at 6:44 PM, Ronald Oussoren  wrote:
>
> What's so bad about IDLE that you'd like to replace it?

That was exactly my previous question. You don't use IDLE either, so
why not to replace it with something that you can actually use, with
something that is at least extensible? So people will be interested to
learn and contribute.

> The obvious alternative to replacing IDLE is to fix whatever is wrong with it.

It is also obvious that developer would better download a decent
editor than bog their mind with once perspective, but now dead
technology IDLE was build upon.

-- 
anatoly t.
___
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] Replacing IDLE

[anatoly techtonik]

On Tue, Nov 10, 2009 at 9:26 PM, Michael Foord
 wrote:
>
>> Then there will be another issue - all editors are based upon some
>> frameworks - I didn't see any popular cross-platform GUI toolkits in
>> Python, so we will inevitably face the need to replace Tkinter with
>> other default GUI toolkit.
>
> This just *won't* happen. (At least not in the forseeable future.) Better
> filter your list to only those IDEs that use Tkinter or have a GUI not
> dependent on packages that aren't already in the standard library.

That is a real stumbling block. There aren't any GUI toolkits in pure
Python to be included alongside the editor, and those Tkinter bindings
that compiled for every platform are just useless. If there is a
reason that we just *won't* let any GUI framework (except Tkinter)
slip into Python distribution then of course, any talk about editor is
just a waste of time. But I'd like to see is that reason is real to
know when to expect the changes.

I've done a small research about Tkinter editors to investigate the
solution you proposed. http://wiki.python.org/moin/PythonEditors shows
that these were made with Tk:

Pye - not true, either switched or wrong project, but PyQT4 -
http://code.google.com/p/pye-editor/
xRope - GPL and probably worse than IDLE -
http://sourceforge.net/projects/xrope/
IDEStudio - enhanced IDLE, dead - http://wiki.python.org/moin/IDEStudio
SourceNavigator - GPL, C and not really an editor -
http://sourcenav.sourceforge.net/

There is only one perspective project called Leo (with MIT license)
that was historically written in Tkinter with the goal (I believe) to
construct pure Python editor. It is editor with outlines unique in the
way that it is able to rewrite itself literally at runtime. I believe
only using such advanced tool one can cope with Tkinter
inconsistencies and limitations. Since the beginning Leo has also
developed PyQT4 interface.

-- 
anatoly t.
___
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] Replacing IDLE

[anatoly techtonik]

On Tue, Nov 10, 2009 at 10:49 PM, "Martin v. Löwis"  wrote:
>
> This is not how it works. We cannot incorporate something into Python
> without explicit consent and support from the author(s). So for any
> editor to be incorporated as a replacement (along with all libraries
> it depends on) we would need a commitment from the author(s) that they
> support the fork that we create (and eventually abandon their
> stand-alone release in favor of the fork).
>

Does that mean even if authors of some imaginary editor agree to
incorporate their code into Python, the framework that it is built
upon will have to be incorporated into Python also (and eventually
abandoned at original location)?

In this situation I see no way we can provide any decent tools for GUI
like for default editor.

Thanks for support.
-- 
anatoly t.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PyPI front page

[anatoly techtonik]

On Fri, Nov 13, 2009 at 9:35 AM, "Martin v. Löwis"  wrote:
>> Ben Finney  benfinney.id.au> writes:
>>> There's a problem with the poll's placement: on the front page of the
>>> PyPI website.
>>
>> Speaking of which, why is it that http://pypi.python.org/pypi and
>> http://pypi.python.org/pypi/ (note the ending slash) return different 
>> contents
>> (the latter being very voluminous)? I always mistake one for the other when
>> entering the URL directly.
>
> As Ian says: setuptools relies on it. It's part of the specification of
> the package index.

Where is that specification? Does it require only
http://pypi.python.org/pypi/ to be voluminous or also
http://pypi.python.org/pypi to provide some search interface for
automatic processing? There should be no problem in moving search page
to the root http://pypi.python.org/ if spec is silent about the
latter.

-- 
anatoly t.
___
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] Pronouncement on PEP 389: argparse?

[anatoly techtonik]

On Tue, Dec 15, 2009 at 12:37 AM, Steven Bethard
 wrote:
>
> If you're only concerned about 2.X, then yes, optparse will *never* be
> removed from 2.X. There will be a deprecation note in the 2.X
> documentation but deprecation warnings will only be issued when the -3
> flag is specified. Please see the "Deprecation of optparse" section of
> the PEP:
>
> http://www.python.org/dev/peps/pep-0389/#deprecation-of-optparse

I do not think that optparse should be deprecated at. It is good at
what it does and its limitations make its starting point less
confusing for people with different backgrounds that Python.

Compare:
http://docs.python.org/library/optparse.html
http://argparse.googlecode.com/svn/tags/r101/doc/index.html

argparse should be recommended as advanced and more featured variant
of optparse - that goes without saying, but forcing people to switch
and annoying them with deprecation messages brings only headache. Just
like optparse is better getopt, the latter could also be useful for
people coming from other languages and porting their libraries to
Python.

I would better concentrate on real code examples how argparse solves
problems and would really want to see
http://www.python.org/dev/peps/pep-0389/#out-of-scope-various-feature-requests
implemented until argparse enters phase where backward incompatible
changes in API are impossible.

I would prefer to see PEP 389 as a document describing proposed
solutions to argument parsing problems rather than petition to replace
one library with another. So, it should display common argument
parsing scenarios (use cases) with examples that are also useful
recipes for documentation. I guess more than 90% people here doesn't
have time to read argparse methods descriptions to see what they could
be useful for.

-- 
anatoly t.
___
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] Fixed URL to 2.6 documentation

[anatoly techtonik]

Greetings,

I'm writing a module for current Python 2.6 and I would like to
reference documentation for Python 2.6, because I am not sure if
behavior won't be changed in further series. So far I can link only
to:

http://docs.python.org/ (stable, 2.6)
http://docs.python.org/dev/ (2.7)
http://docs.python.org/dev/py3k/

When stable changes to 2.7 my reference will point to the different
version than I was meant when writing comment. It is possible to link
to docs for minor 2.6.4 http://www.python.org/doc/2.6.4/ but I would
like to link to latest version of docs in 2.6 branch that may not yet
found way into official minor release.

-- 
anatoly t.
___
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 2.6.5

[anatoly techtonik]

On Tue, Feb 2, 2010 at 8:08 PM, Barry Warsaw  wrote:
> I'm thinking about doing a Python 2.6.5 release soon.  I've added the
> following dates to the Python release schedule Google calendar:
>
> 2009-03-01 Python 2.6.5 rc 1
> 2009-03-15 Python 2.6.5 final
>
> This allows us to spend some time on 2.6.5 at Pycon if we want.  Please let me
> know if you have any concerns about those dates.

I've noticed a couple of issues that 100% crash Python 2.6.4 like this
one - http://bugs.python.org/issue6608  Is it ok to release new
versions that are known to crash?

-- 
anatoly t.
___
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 2.6.5

[anatoly techtonik]

On Tue, Feb 9, 2010 at 12:57 PM, Antoine Pitrou  wrote:
> Le Tue, 09 Feb 2010 12:16:15 +0200, anatoly techtonik a écrit :
>>
>> I've noticed a couple of issues that 100% crash Python 2.6.4 like this
>> one - http://bugs.python.org/issue6608  Is it ok to release new versions
>> that are known to crash?
>
> I've changed this issue to release blocker. What are the other issues?

I've basically run a query to get all "crash" type issues for Python 2.6
http://bugs.python.org/iss...@search_text=&title=&@columns=title&id=&@columns=id&stage=&creation=&creator=&activity=&@columns=activity&@sort=activity&actor=&nosy=&type=1&components=&versions=1&dependencies=&assignee=&keywords=&priority=&@group=priority&status=1&@columns=status&resolution=&nosy_count=&message_count=&@pagesize=50&@startwith=0&@queryname=&@old-queryname=&@action=search

There are 65 entries and among them I can additionally confirm:
http://bugs.python.org/issue3720
http://bugs.python.org/issue7788
http://bugs.python.org/issue5765

-- 
anatoly t.
___
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 2.6.5

[anatoly techtonik]

On Tue, Feb 9, 2010 at 11:55 PM, "Martin v. Löwis"  wrote:
>> Le Tue, 09 Feb 2010 12:16:15 +0200, anatoly techtonik a écrit :
>>> I've noticed a couple of issues that 100% crash Python 2.6.4 like this
>>> one - http://bugs.python.org/issue6608  Is it ok to release new versions
>>> that are known to crash?
>>
>> I've changed this issue to release blocker. What are the other issues?
>
> For a bug fix release, it should (IMO) be a release blocker *only* if
> this is a regression in the branch or some recent bug fix release over
> some earlier bug fix release.

Is it possible to make exploits out of crashers?

-- 
anatoly t.
___
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 2.6.5

[anatoly techtonik]

On Wed, Feb 10, 2010 at 8:25 AM, Antoine Pitrou  wrote:
>
> Besides, as Barry said, classifying a bug as blocker is also a good way
> to attract some attention on it. Other classifications, even "critical",
> don't have the same effect.

Unfortunately, not many people have privilege to change bug properties
to attract attention to the issues. For example, this patch -
http://bugs.python.org/issue7582 is ready to be committed, it is
trivial, not a release blocker, but would be nice be released. How to
make it evident if nobody except committers is able to add any
keywords to the issue? I suspect that even committers do not receive
this privilege automatically.

-- 
anatoly t.
___
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] Google Groups Mirror

[anatoly techtonik]

What is the point in maintaining archive listed in
http://mail.python.org/mailman/listinfo/python-dev if it is not
searchable?
Recently I needed to find old thread about adding tags to roundup but couldn't.

GMane archive doesn't search -
http://news.gmane.org/navbar.php?group=gmane.comp.python.devel&query=roundup+tags
and Google Group archive is private http://groups.google.com/group/python-dev

How about opening an official read-only Google Group mirror? Then it
will be possible to subscribe to notifications to just interesting
threads.
-- 
anatoly t.
___
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] Google Groups Mirror

[anatoly techtonik]

On Sun, Feb 14, 2010 at 8:36 PM, Benjamin Peterson  wrote:
> 2010/2/14 anatoly techtonik :
>> What is the point in maintaining archive listed in
>> http://mail.python.org/mailman/listinfo/python-dev if it is not
>> searchable?
>
> It is:
>
> Google "some interesting python thing
> site:mail.python.org/mailman/pipermail/python-dev"

Doesn't work.
http://www.google.com/search?q=site:mail.python.org/mailman/pipermail/python-dev+roundup+tags

Seems that mailman in your query is not needed. This search is
definitely not simple to use. How about to add Google search form to
http://mail.python.org/mailman/listinfo/python-dev ?

-- 
anatoly t.
___
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] Google Groups Mirror

[anatoly techtonik]

On Sun, Feb 14, 2010 at 8:58 PM, Benjamin Peterson  wrote:
> 2010/2/14 anatoly techtonik :
>> On Sun, Feb 14, 2010 at 8:36 PM, Benjamin Peterson  
>> wrote:
>>> 2010/2/14 anatoly techtonik :
>>>> What is the point in maintaining archive listed in
>>>> http://mail.python.org/mailman/listinfo/python-dev if it is not
>>>> searchable?
>>>
>>> It is:
>>>
>>> Google "some interesting python thing
>>> site:mail.python.org/mailman/pipermail/python-dev"
>>
>> Doesn't work.
>> http://www.google.com/search?q=site:mail.python.org/mailman/pipermail/python-dev+roundup+tags
>
> But 
> http://www.google.com/search?q=roundup+tags+site%3Amail.python.org%2Fpipermail%2Fpython-dev
> does.

Yep. Just like I said. So, how about to add Google search form to
http://mail.python.org/mailman/listinfo/python-dev ?

-- 
anatoly t.
___
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] Google Groups Mirror

[anatoly techtonik]

On Sun, Feb 14, 2010 at 9:03 PM, Benjamin Peterson  wrote:
> 2010/2/14 anatoly techtonik :
>> Yep. Just like I said. So, how about to add Google search form to
>> http://mail.python.org/mailman/listinfo/python-dev ?
>
> You'll have to talk to postmas...@python.org about that.

Crossposted. And what about per-thread subscription that comes with
Google Groups? I do not need it, because I am subscribed, but if that
could be possible - I'd unsubscribe to read it from web receiving
notification only about interesting topics.

Who owns http://groups.google.com/group/python-dev ?
-- 
anatoly t.
___
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] Google Groups Mirror

[anatoly techtonik]

On Mon, Feb 15, 2010 at 1:31 AM, Barry Warsaw  wrote:
>
>> What is the point in maintaining archive listed in
>> http://mail.python.org/mailman/listinfo/python-dev if it is not
>> searchable?
>> Recently I needed to find old thread about adding tags to roundup but 
>> couldn't.
>>
>> GMane archive doesn't search -
>> http://news.gmane.org/navbar.php?group=gmane.comp.python.devel&query=roundup+tags
>> and Google Group archive is private http://groups.google.com/group/python-dev
>>
>> How about opening an official read-only Google Group mirror? Then it
>> will be possible to subscribe to notifications to just interesting
>> threads.
>
> Try mail-archive.com, it's searchable.
>
> http://www.mail-archive.com/python-dev@python.org/

Thanks. Still an official search form will be welcomed as well as
per-thread subscriptions, and not only for python-dev.

Crossposted to postmas...@python.org

-- 
anatoly t.
___
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] Release timer for Core Development page

[anatoly techtonik]

I've got another idea of having a release timer on
http://python.org/dev/ page together with link to generated release
calendar.
It will help to automatically monitor deadlines for feature fixes in
alpha releases without manually monitoring this mailing list.

There is already a navigation box on the right side where this
information fits like a glove.
Does anybody else find this feature useful for Python development?

-- 
anatoly t.
___
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] Add UTC to 2.7 (PyCon sprint idea)

[anatoly techtonik]

Hello,

So far, Python timezone handling is far from "pythonic". There is no
function to get current UTC offset, intuitive API to get DST of
current time zone and whenever it is active, no functions to work with
internet timestamps (RFC 3339). In my case [1] it took about one month
and five people to get the right solution for a valid RFC 3339
timestamp. One of the reasons I see is that date/time functions are
implemented in C, they expose C API, and there are not many people who
can help and patch them.

I am sure many current Python users will appreciate UTC functions and
improved date/time API more than any new language features. That's why
I would like to propose this enhancements for a coding spring on
forthcoming PyCon. I am located in Europe and can't attend PyCon, but
I summarized date/time issues related to UTC below.

More open UTC-related Python issues:
http://bugs.python.org/issue1647654  No obvious and correct way to get
the time zone offset
http://bugs.python.org/issue1667546  Time zone-capable variant of time.localtime
http://bugs.python.org/issue7662 time.utcoffset()
http://bugs.python.org/issue7229 [PATCH] Manual entry for
time.daylight can be misleading
http://bugs.python.org/issue5094 datetime lacks concrete tzinfo
impl. for UTC
http://bugs.python.org/issue7584 datetime.rfcformat() for Date and
Time on the Internet (support RFC 3339, ISO 8601 datetime format)
http://bugs.python.org/issue665194   datetime-RFC2822 roundtripping
http://bugs.python.org/issue6280 calendar.timegm() belongs in time
module, next to time.gmtime()

All solutions require C expertise. If it will be impossible to find
experts able to modify current implementation, then perhaps it could
be real to create Python stub for coding solution in Python later?

FWIW, this proposal is from my other issue about problems with Python
date/time in separate tracker on Google Code [2].

[1] http://bugs.python.org/issue7582[patch] diff.py to use iso timestamp
[2] http://code.google.com/p/rainforce/issues/detail?id=10python:
date/time is a mess
-- 
anatoly t.
___
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 UTC to 2.7 (PyCon sprint idea)

[anatoly techtonik]

On Tue, Feb 16, 2010 at 1:52 PM, Victor Stinner
 wrote:
>> So far, Python timezone handling is far from "pythonic". There is no
>> function to get current UTC offset, (...)
>
> There is the time.timezone attribute: UTC offset in seconds.

It is correct only if DST is not in effect.

On Tue, Feb 16, 2010 at 5:26 PM, Tres Seaver  wrote:
>
> s...@pobox.com wrote:
>>
>> While incorporating dateutil into the core would be nice (in my opinion at
>> least), I was really thinking of pytz: http://pytz.sourceforge.net/
>
> Because timezones are defined politically, they change frequently.  pytz
> is released frequently (multiple times per year) to accomodate those
> changes:  I can't see any way to preserve that flexibility if the
> package were part of stdlib.

Actual TZ information can be shipped with every Python release, but..
If pytz package is available and it's newer - library functions may
use its data instead. Of course, this should be documented as official
way to maintain TZ info up-to-date.

If pytz to be included in standard library - it should still be
distributed as separate package to provide more frequent TZ updates
and updates to older Python versions.


On Wed, Feb 17, 2010 at 1:32 PM, Lennart Regebro  wrote:
> There is no need to stick Pytz in the standard library. It's available
> on PyPI, updated frequently, etc. What we can do is point to it from
> the documentation.

It will still require workarounds and bridges to make API in user
scripts convenient, i.e.

try:
  import pytz
  mydatetime = PytzDatetime()
catch ImportError:
  mydatetime = ClassicDatetime()

The goal is to reduce workarounds and avoid repeated code in Python scripts.



Leaving pytz aside, does everybody feel comfortable with setting a
Wave for API design of date/time issues and the stuff to be done? If
there will be an API draft and current list of stuff - I can try to do
some work in "offline" mode.

-- 
anatoly t.
___
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] Tracker reviews workflow and flags

[anatoly techtonik]

I want to push some of my patches before 2.7 and use 5-1 rule for
that, but I can't come up with any review workflow other than mailing
status of my comments to the issues here. I can't mark issues in any
way. How about giving users ability to set flags or keywords? Maybe
entering a separate field like "Review status"?

Real world example with issue8151. It is an issue with a trivial patch
in it. Everything what is needed is to dispatch it to stable `commit
queue` and port to trunk. It is not 'easy' - it is 'trivial', but I
have no means to mark it as 'easy' either, so even this trivial fix
lies in tracker for three days waiting for review.

About 'easy' flag:
"6  easyThis is an easy task (e.g. suitable for GHOP or bug day 
beginners)"
It seems that it is for the issue that requires a patch, but if the
patch is already there and nobody wants to commit it - what should I
do?


Finally, review queue proposal.
To follow 5-1 rule, I need to review 5 issues, before mine is
reviewed, so I need some help from tracker.
1. I lack expertise in certain areas (C/C++, Mac OS, etc.), so I would
like to hide some issues under "Needs review" query, so they won't
bother me (if too many people marked issues in this way - the stats
may become a good reason for highly professional bug party)
2. I need ability to set "Needs review" flag back. Some issues were
once reviewed, but since then they've got modified and need further
comments.  The need the review again. That means pushed back _into the
end_ of patch queue.
3. Setting bug dependency by users. Often nobody wants to care about
issue, because it is just too long, there is much irrelevant comments
and nobody has time to read it. We don't have personal digg-like
comment filters to cope with the amount of text to be brain-loaded.
But it is possible to refactor such issue thread into separate
digestable issue/issues.


P.S.  About personal comment filters if anybody is interested in that.
Digg-like +1, -1 are good for voting, but for filtering it would be
nice to: 1. have several filters for different aspects of the thread,
2. have JS filter by marking individual phrases in comments and adding
ranges to filter using jquery / ajax

This way reviews will be more fun and easy.
-- 
anatoly t.
___
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] At least one package management tool for 2.7

[anatoly techtonik]

I wonder if there are many people here who don't use some kind of
"easy_install" package for package management in their Python /
virtualenv installations? I propose to include at least one such
package that is capable to auto-update itself in Python 2.7

C:\~env\Python27>python.exe -m easy_install
C:\~env\Python27\python.exe: No module named easy_install

C:\~env\Python27>python.exe -m pip
C:\~env\Python27\python.exe: No module named pip


It bugs me when I have to troubleshoot things on yet another machine
that doesn't have some kind of `setuptools` installed. Or when I have
to test some bug in my package on different Python version with a
clean install and need some dependencies.

-- 
anatoly t.
___
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] Joel Spolsky on Mercurial

[anatoly techtonik]

On Fri, Mar 19, 2010 at 11:00 AM, Dirkjan Ochtman  wrote:
>> Having gotten that far, I think this might be worth referencing in new dev
>> docs.
>
> Will do. I finally read hginit yesterday, after having seen people
> rave about it on twitter for a few weeks, and it's a very friendly
> introduction.

I more like hands-on approach that does use real world workflow
instead of academic examples. For example, tutorial like Ondrej Certik
made for SymPy patches using Mercurial queues.
http://docs.sympy.org/sympy-patches-tutorial.html  It goes straight
from the problem in SymPy development you'd like to resolve for
yourself and then shows how Mercurial helps with it. If you have more
time to dig - you may read a book or Joel series.

-- 
anatoly t.
___
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] At least one package management tool for 2.7

[anatoly techtonik]

On Wed, Mar 24, 2010 at 12:26 PM, Tarek Ziadé  wrote:
>
> Distutils2 is planned to be reintegrated in the stdlib in Python 3.3,
> and my goal is to release it when Python 2.7 final is released.

Does that means "after" Python 2.7, because I meant it to be "before"
or at least "with"?

> The open question is: do we want to include a full installer that
> takes care of installing / removing dependencies as well ?

If there is a risk to get nothing at all in 2.7 distribution, because
it just won't be ready/accepted by that time, then I it is certainly
optional.

> But the "auto-update" story seems interesting, can you expand on this ?

Sure. Package management tool should have an ability to update itself
when required regardless of Python release. For example::

python.exe -m easy_install setuptools

This will get you new version of `setuptools` and `easy_install`
module from it automagically. You do not need to install new version
of `setuptools` manually or copy files from SVN if you want to see
fixes before next Python release. The stuff you would likely need to
do with distutils bugs, which I personally find awkward.

Package management is orthogonal to Python releases, and it is more
oriented at Python users who don't like to wait or follow PEPs. That's
why package management tool such as 'easy_install' has shorter
development cycle, and it should faster react to user feedback. What
can be one of the reasons that no package management tool is included
with Python.

In various README you may often see "requires setuptools > 0.6c9" or
similar. I can't see why package management tool can not detect this
dependency and propose to update itself.

If it is impossible to ship the whole package management system then
at least Python distribution may carry small bootstrap script for it.
When user tries to execute package management tools, it warns him that
these are not installed and gives a hint where to get them::

> python -m easy_install bla-bla-bla
Error: easy_install module is not shipped with this Python release.
Please execute the following command to install the latest version.

python -m easy_bootstrap

-- 
anatoly t.
___
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] At least one package management tool for 2.7

[anatoly techtonik]

> Sure. Package management tool should have an ability to update itself when 
> required regardless of Python release. For example::
>
> python.exe -m easy_install setuptools
>

This should be:

python -m easy_install -U setuptools

P.S. Wave effect. =)
-- 
anatoly t.
___
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] Request for commit access

[anatoly techtonik]

On Wed, Mar 24, 2010 at 12:34 AM, "Martin v. Löwis"  wrote:
>
> Procedurally, I wonder where people got the notion from that you can or
> need to apply for commit access. IIUC, it used to be the case that you
> would be recommended for commit access, by some (more or less senior)
> fellow committer. That person then would work on actually getting commit
> access to the new committer - perhaps by first asking other people in
> private, to avoid any public embarrassment if access is ultimately
> denied. IMO, that committer should then also mentor the new guy, both by
> helping out in difficult cases, and by closely following commits to see
> whether (possibly unstated) conventions are being followed.

That's an ideal case, but it doesn't work, because more or less senior
committers are already too busy. If they do not even have time to
review issues, followup on patches  - how can they monitor who reached
the appropriate karma level?
-- 
anatoly t.
___
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] Bootstrap script for package management tool in Python 2.7 (Was: Re: [Distutils] At least one package management tool for 2.7)

[anatoly techtonik]

So, there won't be any package management tool shipped with Python 2.7
and users will have to download and install `setuptools` manually as
before:

  "search" -> "download" -> "unzip" -> "cmd" -> "cd" -> "python
setup.py install"


Therefore I still propose shipping bootstrap package that instruct
user how to download and install an actual package  management tool
when users tries to use it. So far I know only one stable tool -
`easy_install` - a part of `setuptools` package.

The required behavior for very basic user friendliness:
1. user installs Python 2.7
2. user issues `python -m easy_install something`
3. user gets message
'easy_install' tool is not installed on this system. To make it
available, download and install `setuptools` package from
http://pypi.python.org/pypi/setuptools/

4. the screen is paused before exit (for windows systems)

Other design notes:
1. if package tries to import `easy_install` module used for
bootstrap, it gets the same ImportException as if there were no
`easy_install` at all
2. bootstrap module is overwritten by actual package when users installs it


So, do we need a PEP for that? How else can I know if consensus is
reached? Anybody is willing to elaborate on implementation?


P.S. Please be careful to reply to relevant lists
-- 
anatoly t.



On Mon, Mar 29, 2010 at 9:37 AM, Tarek Ziadé  wrote:
> 2010/3/29 anatoly techtonik :
> [..]
>> It is really hard to follow. You should at least change subjects when
>> switching topic.
>
> I was talking about the work going on and the decisions taken lately.
>
> I never change topics of threads mails when there's less than 100 mails,
> because I find it way more confusing :)
>
>>
>> So, what is the verdict? Will there be a package management tool or
>> bootstrap package for it shipped with Python 2.7 or not?
>
> As I said in the mail you've quoted, all improvements are made in
> Distutils2. So the answer is no.
> Python 2.7b1 is due in less than a week anyways, so any new
> development on this topic will happen after.
>
> Basically Python 2.7 == Python 2.6 in term of packaging.
>
> Regards
> Tarek
>
> --
> Tarek Ziadé | http://ziade.org
>
___
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] GSoC 2010 is on -- projects?

[anatoly techtonik]

I would vote for allowing student work on community infrastructure
tasks. Tracker, Wiki, Web site management tools are all outdated and
everybody who cares agrees that they've seen a better tools.

-- 
anatoly t.



On Fri, Mar 19, 2010 at 4:36 AM, C. Titus Brown  wrote:
> Hi all,
>
> once again, the PSF has been accepted as a mentoring foundation for the Google
> Summer of Code!  This year, we're going to emphasize python 3 porting, so
> please think of projects you'd like to see tackled.
>
> Please submit ideas for projects as soon as possible, as students will be able
> to start applying soon.  You can add them to this page:
>
>   http://wiki.python.org/moin/SummerOfCode/2010
>
> You can subscribe to the mentors list here,
>
>   http://mail.python.org/mailman/listinfo/soc2010-mentors
>
> and the general discussion list (students included) here:
>
>   http://mail.python.org/mailman/listinfo/soc2010-general
>
> thanks,
> --titus
> --
> C. Titus Brown, c...@msu.edu
> ___
> 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/techtonik%40gmail.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] Bootstrap script for package management tool in Python 2.7 (Was: Re: [Distutils] At least one package management tool for 2.7)

[anatoly techtonik]

On Mon, Mar 29, 2010 at 10:55 AM, Tarek Ziadé  wrote:
>>
>> Therefore I still propose shipping bootstrap package that instruct
>> user how to download and install an actual package  management tool
>> when users tries to use it. So far I know only one stable tool -
>> `easy_install` - a part of `setuptools` package.
>
> There are other tools to install something in a vanilla Python :
>
> - pip  (which also have an uninstall feature)
> - distutils
> - distribute

distutils is not a `package management` tool, because it doesn't know
anything even about installed packages, not saying anything about
dependencies.

`pip` and `distribute` are unknown for a vast majority of Python
users, so if you have a perspective replacement for `easy_install` -
it can be said in bootstrap package message. There is no problem with
packages that require `setuptools` either - they will require
`setuptools` as dependency anyway.

For now there are two questions:
1. Are they stable enough for the replacement of user command line
`easy_install` tool?
2. Which one is the recommended?

P.S. Should there be an accessible FAQ in addition to ML?

>>
>> The required behavior for very basic user friendliness:
>> 1. user installs Python 2.7
>> 2. user issues `python -m easy_install something`
>> 3. user gets message
>> 'easy_install' tool is not installed on this system. To make it
>> available, download and install `setuptools` package from
>> http://pypi.python.org/pypi/setuptools/
>
> Are you thinking about something generic ?
>
> Like, being able to call :
>
> $ python -m ANYTHING
>
> And get an error message saying that the ANYTHING script is not installed ?
> Then have a registry somewhere to get the name of the project that
> owns the ANYTHING script ?
>

No. To get something in 2.7 I would refrain from developing into this
direction for now.

> [..]
>> So, do we need a PEP for that? How else can I know if consensus is
>> reached? Anybody is willing to elaborate on implementation?
>
> I see two paths here:
> 1 - do you want to define a general mechanism for Python to install scripts ?
> 2 - are you just suggesting to have this mechanism only for Package Managers ?

3 - I want current "best practice" for installing Python modules with
dependencies from PyPI to be shipped with Python 2.7 by default

Answering your questions:
1. I want to have some user-friendly way for installing Python
scripts, but I am more concerned that I will miss `easy_install` in
Python 2.7
2. Bootstrap script is aimed at users. Package managers are assumed to
already have their package
at PyPI and provide install instructions that involve `easy_install`,
so nothing is required to be done on their part.

>
> In case of 2), what you would need to do is propose an extension to
> PEP 376, we are currently working
> on, then we can add it there once people have discussed it on
> distutils-SIG, or maybe create a new PEP if the topic is too big to
> fit in 376.

PEP 376 is completely irrelevant to user side boot package proposal.
This proposal is to recommend whatever package managing tool you think
user need and instruct how to get the tool. The boot package doesn't
know anything at all about how packages are managed.


>> P.S. Please be careful to reply to relevant lists
>
> Yes, so if it's 2) let's keep this thread in Distutils-SIG.
> Cross-posting like this makes it hard to follow.

My vision is that decision about having bootstrap package or not in
2.7 should be in python-dev and specific packaging, implementation and
pip/distutils/distribute questions in distutils-sig.

-- 
anatoly t.
___
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] [Distutils] Bootstrap script for package management tool in Python 2.7 (Was: Re: At least one package management tool for 2.7)

[anatoly techtonik]

2010/3/29 Lennart Regebro :
> On Mon, Mar 29, 2010 at 09:30, anatoly techtonik  wrote:
>> Therefore I still propose shipping bootstrap package that instruct
>> user how to download and install an actual package  management tool
>> when users tries to use it. So far I know only one stable tool -
>> `easy_install` - a part of `setuptools` package.
>
> We can't ship *A* bootstrap script until there is *A* package
> management tool in the Python world. Currently there are three. :)
>
> In short: The tools that exist are not ready yet.

Ok. How about shipping bootstrap script only for `easy_install` tool for now?

-- 
anatoly t.
___
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] Bootstrap script for package management tool in Python 2.7 (Was: Re: [Distutils] At least one package management tool for 2.7)

[anatoly techtonik]

On Mon, Mar 29, 2010 at 12:15 PM, Tarek Ziadé  wrote:
> [..]
>> distutils is not a `package management` tool, because it doesn't know
>> anything even about installed packages, not saying anything about
>> dependencies.
>
> At this point, no one knows anything about installed packages at the
> Python level.

Users do not care about this, and `distutils` doesn't know this even
at package level.

> Keeping track of installed projects is a feature done within each
> package managment system.
>
> And the whole purpose of PEP 376 is to define a database of what's
> installed, for the sake of interoperability.

That's great. When it will be ready everybody would be happy to make
their package management tool compliant.

>>
>> `pip` and `distribute` are unknown for a vast majority of Python
>> users, so if you have a perspective replacement for `easy_install` -
>
> Depending on how you call a Python user, I disagree here. Many people
> use pip and distribute.
>
> The first one because it has an uninstall feature among other things.
> The second one because it fixes some bugs of setuptools and provides
> Python 3 support

I do not mind if we can distribute three stubs, they will also serve
as pointers for a better way of packaging when an ultimate tool is
finally born. Me personally is willing to elaborate for `easy_install`
stub in 2.7.

>>
>> For now there are two questions:
>> 1. Are they stable enough for the replacement of user command line
>> `easy_install` tool?
>> 2. Which one is the recommended?
>>
>> P.S. Should there be an accessible FAQ in addition to ML?
>
> This FAQ work has been started in th "HitchHicker's guide to
> Packaging" you can find here:
>
> http://guide.python-distribute.org

I can see any FAQ. To me the FAQ is something that could be posted to
distutils ML once a month to reflect current state of packaging. It
should also carry version number. So anybody can comment on the FAQ,
ask another question or ask to make a change.

> Again, any new code work will not happen because 2.7 is due in less
> than a week. Things are happening in Distutils2.

That doesn't solve the problem. Bootstrap script can be written in one
day. What we need is a consensus whatever this script is welcomed in
2.7 or not? Who is the person to make the decision?

> Now, for the "best practice" documentation, I think the guide is the
> best plce to look at.

Let's refer to original user story:
"I installed Python and need a quick way to install my packages on top of it."
"I execute `easy_install something` as said in installation manual,
but nothing/error happens."

> [..]
>> PEP 376 is completely irrelevant to user side boot package proposal.
>
> It is, since it proposes an uninstall script called via -m. So having
> a install script called by -m is definitely its business.

The scope of my proposal is a bootstrap script that instructs user how
to install the package management tool of user's choice if this tool
is not yet installed on user system (this is the case with new Python
installation).  If you'll come up with a better way of package
management - you will update this bootstrap script with relevant
information in future Python releases.

Right now it is essential to get this _feature_ in Python 2.7 until
2.7 is frozen for new features. The script that shows message upon
invocation and is overwritten by the version of the package it
proposes to install. Is it hard to do?

>> My vision is that decision about having bootstrap package or not in
>> 2.7 should be in python-dev and specific packaging, implementation and
>> pip/distutils/distribute questions in distutils-sig.
>
> If the mentioned bootstrap script is about a package managment system,
> you should keep the discussion in distutils-SIG I think.

If there will be no bootstrap script in 2.7, I won't have any
motivation to continue discussion until 2.8 deadline is near. Of
course I will be disappointed, because I will have to explain
everything to 2.7 users again and again instead of letting them
execute one command and follow its instructions.
-- 
anatoly t.
___
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] Google Groups mirror (Was: Bootstrap script for package management tool in Python 2.7)

[anatoly techtonik]

On Mon, Mar 29, 2010 at 4:50 PM, Tarek Ziadé  wrote:
> Anatoly, I am now answering only in Distutils-SIG.
>
> On Mon, Mar 29, 2010 at 3:45 PM, anatoly techtonik  
> wrote:
> [..]

Seems like I start to hate mailing lists even more with all this
message duplication and thread following nightmare. Why can't people
here create a Google Groups mirror?

-- 
anatoly t.
___
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] Bootstrap script for package management tool in Python 2.7 (Was: Re: [Distutils] At least one package management tool for 2.7)

[anatoly techtonik]

2010/3/29 Nick Coghlan :
> anatoly techtonik wrote:
>> So, there won't be any package management tool shipped with Python 2.7
>> and users will have to download and install `setuptools` manually as
>> before:
>
> Until the discussed package management tools support a robust inventory
> and uninstallation system that plays well with directly installed Python
> packages, you won't find widespread support on python-dev for endorsing
> any of them.

This wasn't the question, but the summary. I would greatly appreciate
if you could provide your feedback on the second part of my letter
that started with "Therefore..."


> Yes, the people who use them love them for good and valid reasons, but
> those who absolutely detest them also do so for good and valid reasons.
> While this is still the case, it would be highly inappropriate for
> python-dev to include bootstrap scripts that direct users to these

Scripts do not _direct_ users - they _help_ users, already directed by
some installation instruction or tutorial, to find and install package
management system they are _trying_ to use.

> The distutils2 work and the various metadata PEPs that have been
> approved recently are all about addressing those limitations in the
> infrastructure. With those in place and flowing through the Python
> package management ecosystem, bootstrapping interoperable package
> management tools is likely to become a reasonable option in the future.

Bootstrap tools evolve together with packaging situation. You may
deprecate package management tool in your future bootstrap scripts if
it is "incompatible" with this Python release. It is just user message
that is a flexible as the mind of its author.

> But we aren't there yet, and won't be for 2.7 or 3.2. From an outsider's
> perspective, the 3.3 time frame appears to be very possible though.

Just a thought about user story my customers would likely write if I
shipped Python as a product:
"As a user, I think Python is suxx, because it makes its users suffer
for a long time from packaging disorder".

-- 
anatoly t.
___
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] Google Groups mirror (Was: Bootstrap script for package management tool in Python 2.7)

[anatoly techtonik]

On Mon, Mar 29, 2010 at 5:15 PM, Antoine Pitrou  wrote:
> anatoly techtonik  gmail.com> writes:
>>
>> Seems like I start to hate mailing lists even more with all this
>> message duplication and thread following nightmare. Why can't people
>> here create a Google Groups mirror?
>
> There are already gmane mirrors, such as:
> http://news.gmane.org/gmane.comp.python.devel

Do you use it yourself for thread subscription?

My point is that gmane mouse clicking interface is insane. They can
not fold quotations. And if you'll look attentively you won't find
most of messages from ongoing discussion about bootstrap script for
package management.
-- 
anatoly t.
___
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] Contribute

[anatoly techtonik]

On Tue, Mar 30, 2010 at 2:20 AM,   wrote:
>
>    Shashwat> Python should have something like gnome-love (
>    Shashwat> http://live.gnome.org/GnomeLove ). Some bugs on bugzilla is
>    Shashwat> tagged with gnome-love which are fairly easy and especially
>    Shashwat> created to help dive in new developers.
>
> I don't know what gnome love is (and would be hesitant to click on any such
> links, especially at work) but on bugs.python.org such items are tagged
> "easy".  Right on the front page is a link with the label "Show Easy".

The difference between "gnome-love" and "easy" tags is that the latter
can only be flagged by code devs (who usually do not have much time to
review bugs).
-- 
anatoly t.
___
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] GSoC 2010 is on -- projects?

[anatoly techtonik]

On Mon, Mar 29, 2010 at 3:30 PM, C. Titus Brown  wrote:
>
>> I would vote for allowing student work on community infrastructure
>> tasks. Tracker, Wiki, Web site management tools are all outdated and
>> everybody who cares agrees that they've seen a better tools.
>
> As long as it's programming, it's allowed by Google.  So let's find a good
> student or two, and outline a few good projects!
>
> I do worry that that kind of work is difficult to evaluate, and requires 
> really
> great communication on both sides...

First we need to compile a list of things to do into one big list. I
see the major problem that there is no "dashboard" that gives an
overview of available/supported community services and their status.
Services that are parts of python.org and those that linked and often
used, but not parts.

Status of service is the amount of opened/languishing
bugs/enhancements. Some services don't have trackers at all. For
example, infrastructure proposals, web site patches is nowhere to
track.

Service on a dashboard should be accompanied by contact points info.

Service should list location of primary repository and mirrors.

Feature creep:
- Service can be monitored for online/offline status.
- Service may have maintenance scripts, which community members can
see, inspect scheduled times for the next run and results of
execution.
- Service may publish stats for further analysis.


After dashboard is ready, it would be nice to unify all Services:
1. Add OpenID/Google support
2. Add searchable Google Groups mirrors
3. Add Google search form to Mailman web interface for hosted groups
4. Register services search with Google (see attach)


Then we need to find a contact point - a person who could be most
helpful for each service and help other students with other specific
tasks. I am not such person for neither service, but I am interested
to help push progress forward.
-- 
anatoly t.
<>___
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] trunk doctests fail to execute with 2.7 alpha

[anatoly techtonik]

I can not compile Python itself, so I use Alpha version to run tests
in trunk. Recent update broke successfully running tests. Any hints
why this happened and how to fix them back?

> C:\~env\Python27\python.exe test\test_doctest.py

doctest (doctest) ... 66 tests with zero failures
Traceback (most recent call last):
  File "test\test_doctest.py", line 2492, in 
test_main()
  File "test\test_doctest.py", line 2474, in test_main
with test_support.check_warnings(*deprecations):
  File "C:\~env\Python27\lib\contextlib.py", line 84, in helper
return GeneratorContextManager(func(*args, **kwds))
TypeError: check_warnings() takes no arguments (1 given)

-- 
anatoly t.
___
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] trunk doctests fail to execute with 2.7 alpha

[anatoly techtonik]

Thanks. I've copied test/test_support.py form Lib into 2.7 alpha
directory and it seems to work.
Although it doesn't seem good to me to mix test support library with
tests themselves.
-- 
anatoly t.



On Thu, Apr 1, 2010 at 2:18 PM, Michael Foord  wrote:
> On 01/04/2010 10:05, anatoly techtonik wrote:
>>
>> I can not compile Python itself,
>
> Building Python on Windows can be done with free tools, so it should be
> possible for you to build Python.
>
> See the instructions here:
>
> http://python.org/dev/faq/#id8
>
>> so I use Alpha version to run tests
>> in trunk. Recent update broke successfully running tests. Any hints
>> why this happened and how to fix them back?
>>
>>
>>>
>>> C:\~env\Python27\python.exe test\test_doctest.py
>>>
>>
>> doctest (doctest) ... 66 tests with zero failures
>> Traceback (most recent call last):
>>   File "test\test_doctest.py", line 2492, in
>>     test_main()
>>   File "test\test_doctest.py", line 2474, in test_main
>>     with test_support.check_warnings(*deprecations):
>>   File "C:\~env\Python27\lib\contextlib.py", line 84, in helper
>>     return GeneratorContextManager(func(*args, **kwds))
>> TypeError: check_warnings() takes no arguments (1 given)
>>
>>
>
> When I run this test with a freshly built Python I get the following:
>
> :\compile\python-trunk\PCbuild
>> python_d.exe ..\Lib\test\test_doctest.py
> doctest (doctest) ... 66 tests with zero failures
> doctest (test.test_doctest) ... 428 tests with zero failures
> [42795 refs]
>
> All the best,
>
>
> Michael Foord
>
> --
> http://www.ironpythoninaction.com/
> http://www.voidspace.org.uk/blog
>
> READ CAREFULLY. By accepting and reading this email you agree, on behalf of
> your employer, to release me from all obligations and waivers arising from
> any and all NON-NEGOTIATED agreements, licenses, terms-of-service,
> shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure,
> non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have
> entered into with your employer, its partners, licensors, agents and
> assigns, in perpetuity, without prejudice to my ongoing rights and
> privileges. You further represent that you have the authority to release me
> from any BOGUS AGREEMENTS on behalf of your employer.
>
>
>
___
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] trunk doctests fail to execute with 2.7 alpha

[anatoly techtonik]

On Thu, Apr 1, 2010 at 3:59 PM, Michael Foord  wrote:
>>
>> Thanks. I've copied test/test_support.py form Lib into 2.7 alpha
>> directory and it seems to work.
>> Although it doesn't seem good to me to mix test support library with
>> tests themselves.
>>
>
> What do you mean by "it doesn't seem good to me to mix test support library
> with tests themselves"? Do you mean to have it in the same directory - where
> would you put it? It isn't *meant* to be a public library, it exists only to
> support the test framework. In Python 3 it has been renamed support.py, but
> lives in the same location.

I mean that usually testing tools/libraries are separated from tests
itself, as well as data. test_support.py is not only located in the
same directory - it is even named in the same way. The test directory
looks like a mess with all these aux data files. But it is hard to
estimate if it would be worthy to separate testing framework from
tests and test data. It may happen that writing and debugging tests
become harder, because Python is not locked into some specific usage
domain.

-- 
anatoly t.
___
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] skip all TestCase methods if resource is not available

[anatoly techtonik]

Currently it is possible to mark individual test methods with:
test_support.requires('network')

However, sometimes it is necessary to skip the whole TestCase if
'network' resource is not available counting the number of skipped
tests at the same time. Are there any standard means to do this?
-- 
anatoly t.
___
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] skip all TestCase methods if resource is not available

[anatoly techtonik]

On Thu, Apr 1, 2010 at 8:02 PM, Florent Xicluna
 wrote:
> 2010/4/1 anatoly techtonik:
>> Currently it is possible to mark individual test methods with:
>>            test_support.requires('network')
>>
>> However, sometimes it is necessary to skip the whole TestCase if
>> 'network' resource is not available counting the number of skipped
>> tests at the same time. Are there any standard means to do this?
>
> Put it in unittest.TestCase.setUp() method. It should be enough.

It fails with error instead if skip, as it should according to
http://docs.python.org/library/unittest.html#unittest.TestCase.setUp

"...any exception raised by this method will be considered an error
rather than a test failure..."
-- 
anatoly t.
___
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] 5 : 1

[anatoly techtonik]

I reviewed 5 issues and want to see http://bugs.python.org/issue7585
committed to Python 2.7


http://bugs.python.org/issue7443
test.support.unlink issue on Windows platform

 i race condition between os.unlink(), TortoiseSVN and os.open()
 - reporter changed OS and can't confirm bug anymore,
   need somebody with Windows and TortoiseSVN installed

http://bugs.python.org/issue6703
cross platform failure and silly test in doctest

 i non-crossplatform check for absolute path when 'module_relative' is True
 - added patch
 - need testcases

http://bugs.python.org/issue1659
Tests needing network flag?

 i skip tests that require network if network is not available
 - added patch
 - it is recommended to split issue to count skipped tests exactly and to
   probe which tests marked as 'require network' are actually don't

http://bugs.python.org/issue2810
_winreg.EnumValue fails when the registry data includes multibyte
unicode characters

 i WindowsError: [Error 234] More data is available when working with _winreg
 - original issue assumed that it is caused by multibyte string, however this
   can not be confirmed anymore
 - exception can be thrown when operating over long keys, this should be
   tested with WinAPI over ctypes, I propose to open new bug for long keys
 - another bug could be opened - it seems impossible to get values of Unicode
   keys with _winreg

http://bugs.python.org/issue3778
python uninstaller leave registry entries

 - confirmed for 2.6.5
 - need windows installer expert to create patch for cleaning empty
registry keys


-- 
anatoly t.
___
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] Code coverage metrics

[anatoly techtonik]

Where can I find public reports with Python tests code coverage?
-- 
anatoly t.
___
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] Code coverage metrics

[anatoly techtonik]

On Tue, Apr 6, 2010 at 12:50 PM, Senthil Kumaran  wrote:
>> Where can I find public reports with Python tests code coverage?
>
> Here:
>
> http://coverage.livinglogic.de/

Thank you. What is the status of getting these stats on python.org?
-- 
anatoly t.
___
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] Code coverage metrics

[anatoly techtonik]

On Tue, Apr 6, 2010 at 7:31 PM, Georg Brandl  wrote:
>
 Where can I find public reports with Python tests code coverage?
>>>
>>> Here:
>>>
>>> http://coverage.livinglogic.de/
>>
>> Thank you. What is the status of getting these stats on python.org?
>
> Wouldn't "status" imply that there is a plan to do so?

It is not that hard to create that plan given that there is a fair
amount of developers who care about code coverage.
-- 
anatoly t.
___
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] stabilizing for a release

[anatoly techtonik]

There is still a serious regression in zipfile module:
http://bugs.python.org/issue6090

And I would really like to see my issue with difflib tabs committed: =/
http://bugs.python.org/issue7585

-- 
anatoly t.



On Wed, Apr 7, 2010 at 4:09 AM, Benjamin Peterson  wrote:
> Let's do it. Please no commits to the trunk which are not aimed at
> fixing the current buildbot failures. Thank you!
>
> 2010/4/6 "Martin v. Löwis" :
>> Benjamin Peterson wrote:
>>> I propose that we freeze the trunk except for fixes for the buildbots. 
>>> Thoughts?
>>
>> Freezing sounds fine with me.
>>
>> Martin
>>
>
>
>
> --
> Regards,
> Benjamin
> ___
> 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/techtonik%40gmail.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] stabilizing for a release

[anatoly techtonik]

On Wed, Apr 7, 2010 at 2:10 PM, "Martin v. Löwis"  wrote:
>
>> There is still a serious regression in zipfile module:
>> http://bugs.python.org/issue6090
>>
>> And I would really like to see my issue with difflib tabs committed: =/
>> http://bugs.python.org/issue7585
>
> None of these are buildbot failures, so they can't go into 2.7b1,
> by the decision of the release manager. Please accept that.

And where will they go?

-- 
anatoly t.
___
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] [RELEASED] 2.7 beta 1

[anatoly techtonik]

On Sun, Apr 11, 2010 at 1:13 AM, average  wrote:
>
> There are so many features taken from 3.0 that I fear that it will
> postpone its adoption interminably (it is, in practice, treated as
> "beta" software itself).  By making it doctrine that it won't be
> official until the next "major" Python release, it will encourage
> those who are able, to just make the jump to 3.0, while those who
> cannot will have the subtle pressure to make the shift, however
> gradual.

> Additionally, it will give the community further incentive
> to make Python3 all that it was intended to be.  Personally, the
> timing of v3 prevented me from fully participating in that effort,
> and, not ignoring the work of those who did contribute, I think many
> of us feel that it has not reached its potential.

The same problem. For me it was possible to participate in standard
library development only after Python Alphas with Windows binaries
were released. I could test both new features and old bugs. Having a
requirement that every developer should be able to compile binaries
has an adverse effect on the quality of standard library.

The absence of public Roadmap also makes it hard to judge the
aforementioned "desired potential".
It could be possible to compile a public list like
http://dungeonhack.sourceforge.net/Roadmap

I am afraid of two things with forthcoming Python releases.
1. feature creeping
2. feature missing
And an overview of Python development in the form of release timer and
roadmap will remove the remnants of fear and uncertainty and surely
attract new people for sprints.

Regardless of said above it is great to feel the hard work behind the
scenes that makes new releases popping up. Thanks.
-- 
anatoly t.
___
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] OS information, tags

[anatoly techtonik]

On Tue, Apr 13, 2010 at 3:54 PM, Nick Coghlan  wrote:
>
>>>            I am surprised to see that the bug-tracker
>>> doesn't have an OS classifier or ability to add
>>> tags ? Since a number of issues reported seem to

Just to remind about my +1 for user editable tags.

>> There is one. In the Components you can do a multiple select and it
>> has Macintosh , Windows as options.
>
> I think that setup dates from the Sourceforge days when we didn't have
> keywords or the ability to add our own fields. Would it make sense to
> put a request on the metatracker to convert these to keywords now that
> they're available?

Keywords are not currently editable by users.

> Or even a separate OS field with "Windows, Mac OS X,
> Linux, *BSD, Other" as the options?

It is not uncommon when code written on Unix can affect both MacOS and
Windows, so you need to be able to select both.

> While there is some Windows and Mac specific code, treating them as
> separate components seems fairly unintuitive.

-- 
anatoly t.
___
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] OS information, tags

[anatoly techtonik]

On Fri, Apr 16, 2010 at 7:13 AM, Steve Holden  wrote:
> Brian Curtin wrote:
>> On Thu, Apr 15, 2010 at 03:20, anatoly techtonik > <mailto:techto...@gmail.com>> wrote:
>>
>>     On Tue, Apr 13, 2010 at 3:54 PM, Nick Coghlan >     <mailto:ncogh...@gmail.com>> wrote:
>>     >
>>     >>>            I am surprised to see that the bug-tracker
>>     >>> doesn't have an OS classifier or ability to add
>>     >>> tags ? Since a number of issues reported seem to
>>
>>     Just to remind about my +1 for user editable tags.
>>
>>
>> -sys.maxint on just about anything user editable except for the title or
>> messages on an issue. I don't think user editable tags on an issue bring
>> anything to the table except making it seem more "web 2.0". Searching
>> user-generated tags would be a nightmare because you'd have to know
>> every combination of some idea in order to get relevant results (e.g.,
>> windows, windoze, window$, win32).
>>
>
> Yes, tight vocabulary control will lead to more consistent classifications.

There can be an interface to normalize tags. Known synonyms can be
merged to the primary list automatically warning user about
substitution. If word is not in primary list the user may propose to
add it to main list. Tags with most user proposals will clearly
indicate candidates for inclusion.

Users still should be able to tag issues with primary set of tags or
propose a tag for an issue.
This will partially take triaging burden off the core developers and
will help to spot people with most proposals as potential contributors
who deserve more tracker privileges.

We need tags gameplay to get people addicted.
-- 
anatoly t.
___
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